Home
AI
Blog

Dirty Frag: Universal Linux LPE Vulnerability Grants Instant Root Access

basanta sapkota
A security researcher just dropped a bombshell on the Linux community. Hyunwoo Kim publicly disclosed Dirty Frag, a local privilege escalation vulnerability that lets any unprivileged user get root on virtually every major Linux distribution. And here's the kicker: the embargo broke before anyone could ship patches. This is not a drill. Working exploit code is already public. If you're running Linux in any capacity—servers, containers, CI runners, development machines—this one demands your attention right now. So, what's the lowdown?

The Quick Version:

  • It's a universal Linux LPE. It chains two kernel bugs to get instant root. 
  • Any local user, even a lowly one, can exploit this to become root on all the major distros. - No CVE yet. The coordinated disclosure got blown up early. -
  • Your immediate fix is to blacklist the esp4, esp6, and rxrpc kernel modules. 
  • Patches are rolling out. AlmaLinux and CloudLinux have them. Upstream fixes are in the works. 
  • This ain't just Copy Fail 2.0. Blacklisting algif_aead won't save you here. 
  • It mangles files in RAM. It directly modifies the page-cache of things like /etc/passwd and /usr/bin/su. Sneaky. 

What Exactly Is This Dirty Frag Thing?

It's in the same family as Dirty Pipe and Copy Fail. Same class of nasty. But while Dirty Pipe messed with pipe buffers, Dirty Frag goes after the frag field in the kernel's socket buffer structure. The heart of the problem? A "zero-copy" send path. Sounds efficient, right? It is. But it's also a nightmare when the kernel does crypto operations on memory an attacker can only read. In Kim's words, on a zero-copy path, the kernel can end up doing in-place crypto on a page cache page the attacker has read access to. The kernel decrypts data right on top of sensitive system files.And attacker controls the output.Now page cache gets poisoned. After that, every time the system reads that file, it sees the attacker's version. Game over. 

How the Attack Actually Works

The clever bit is it chains two separate vulnerabilities. Each one covers for the other's weaknesses. That's why it's so universal. First, there's the xfrm-ESP page-cache write. This one exploits how esp_input() handles fragmented socket buffers. There's a code path that skips the "copy-on-write" safety step, letting the kernel do crypto directly on the attacker's controlled page. It gives a potent 4-byte write primitive. But there's a catch: you need CAP_NET_ADMIN to set it up, which usually means you need user namespace privileges. Some distros, like Ubuntu, lock. that down by default. Enter the second bug: the RxRPC page-cache write. This one doesn't need namespace privileges at all. Not every distro loads rxrpc.ko, but Ubuntu does by default. It's the perfect bridge. By combining both, an attacker can get root on any major distro, regardless of namespace settings or which modules are loaded. 

The Exploit Flow

It targets /usr/bin/su specifically. Here's the gist:

  1. The attacker gets their foot in the door with either the ESP variant or the RxRPC variant. 2. They use splice() to plant a read-only page cache page into a socket buffer. 3. The kernel does its in-place crypto magic on that page, writing the attacker's data. 4. The first 192 bytes of /usr/bin/su's page cache get replaced with a tiny root-shell program. 5. The attacker just runs /usr/bin/su. Boom. Root shell. No password needed because the whole PAM authentication gets completely bypassed. One command. Root. That's it. Why This One Hurts So Much

Several things make Dirty Frag particularly brutal:

It's everywhere. Ubuntu, Debian, RHEL, Fedora, AlmaLinux, CloudLinux... You name it. It's easy. Proof-of-concept code is on GitHub. The researcher released it after the embargo broke, having talked with kernel and distro security teams first. It sidesteps your old fix. If you blacklisted algif_aead for Copy Fail, tough luck. Dirty Frag doesn't care. No CVE to track. The broken embargo means no official identifiers yet. Makes talking about it harder. It lives in RAM. The corruption is in the page cache, not on disk. It sticks around until you reboot or clear the cache. 

Your To-Do List: Mitigation Now

Until patched kernels are everywhere, blacklist those three modules. Run this:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf. Rmmod esp4 esp6 rxrpc 2>/dev/null; true"

This stops the vulnerable modules from loading and tries to unload them if they're already active. Heads up on side effects:

  • esp4/esp6 power IPsec. Kill them, and you kill your IPsec tunnels if they use the kernel data path. Don't do this on hosts running strongSwan or Libreswan. - rxrpc is basically only for AFS clients. Most of you don't have it. If you're on AlmaLinux and have kernel-modules-partner installed from the Devel repo, get rid of it: sudo dnf remove kernel-modules-partner. 

Clear the Cache After You Mitigate

The exploit corrupts files in RAM. If a system might have been hit before you locked things down, flush the page cache to evict any tainted pages:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

Safe to run on live systems. It just dumps clean cache. 

Patches Are Coming In Hot

Despite the embargo mess, distros are moving fast. AlmaLinux already has patched kernels from the upstream fix in testing repos. - AlmaLinux 8. kernel-4.18.0-553.123.2.el8_10 and up

  • AlmaLinux 9: kernel-5.14.0-611.54.3.el9_7 and up
  • AlmaLinux 10: kernel-6.12.0-124.55.2.el10_1 and up

To grab the testing kernel on AlmaLinux:

sudo dnf install -y almalinux-release-testing
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
sudo reboot

CloudLinux is on it too, prepping kernels and KernelCare livepatches. They've also added the exploit's indicators to Imunify360's blacklist. Upstream, the ESP fix is in the netdev tree. The RxRPC fix is circulating on the netdev mailing list. After you update and reboot, double-check you're on a fixed kernel:

uname -r
rpm -q kernel

The Bigger, Unsettling Picture

Dirty Frag is the third major page-cache corruption bug we've seen recently, after Dirty Pipe and Copy Fail. It's becoming a pattern. Something's fundamentally off with how the kernel handles zero-copy paths and page ownership. Here's a chilling thought: the researcher found this bug within a day of Copy Fail going public. Impressive? Absolutely. But also terrifying. If a good guy can spot it fast, so can the bad guys. The kernel community has to rethink its assumptions. When splice() hands off a page reference, the receiving code needs to treat it as read-only unless it explicitly makes a copy. Right now, too many code paths violate that. 

So, What Do You Do?

  1. Blacklist those modules now if patching isn't immediate. 
  2. Flush your page cache to clean out any potential corruption. 
  3. Update your kernel the second your distro releases a fix.
  4. Check your dependencies before breaking IPsec or AFS in production. 
  5. Watch for the CVEs once they're officially assigned. Running multi-tenant environments, container build farms, or CI runners where untrusted users get a shell? Treat this as a five-alarm fire. 

Final Word

Dirty Frag is the real deal. Universal impact, dead-simple exploitation, and public exploit code make it a perfect storm. The module blacklist is a band-aid.Yet real medicine is updating your kernels as soon as they're available. Stay sharp. This family of bugs isn't going away. We're going to see more variants as researchers keep picking at the kernel's zero-copy paths. Have you rolled out the mitigation? Run into any issues with the blacklist breaking your stuff? Talk about it in the comments. Let's help each other out. 

Sources.

Post a Comment