The exploit code? Already live on GitHub. The technical write-up is public for anyone to dissect. CloudLinux teams are in a sprint right now, rushing to build patched kernels and KernelCare livepatches for every affected version. If you're running CloudLinux 7h, 8, 9, or 10, the clock is ticking. You need to act before someone with shell access beats you to the punch.
The Quick and Dirty on Dirty Frag
Let's cut through the noise. Here's what you absolutely need to know:
Dirty Frag is a local privilege escalation monster hiding in the Linux kernel's xfrm networking code. It chains two separate flaws to hand over the keys to the kingdom, root access.
The cat's out of the bag. The exploit works on virtually every major Linux distro from the last nine years or so. Yeah, since 2017.
CloudLinux is on it. Patched kernels are coming for CL7h, CL8, CL9, and CL10. KernelCare patches are in the works for all of them.
You need a stopgap, now. The immediate fix is to blacklist three kernel modules: esp4, esp6, and rxrpc.
Imunify360 gives you a buffer, not a shield. It has extra protections via blacklisted IOCs, but it's no substitute for a kernel patch.
Copy Fail mitigations won't save you here. If you only blacklisted algif_aead, your systems are still wide open. Dirty Frag plays in a completely different sandbox.
So, What Is This Thing, Exactly?
Dirty Frag is in the same shady family as Dirty Pipe and Copy Fail. Same idea: trick the kernel into writing to memory it shouldn't. But while Dirty Pipe messed with pipe buffers, Dirty Frag goes after the frag part of sk_buff. That's the basic data structure Linux uses for network packets. Think of it as the kernel's internal shipping label for data.
A security researcher named Hyunwoo Kim found it. And it's clever. It chains two separate bugs:
First, a flaw in the esp_input() function that's been lurking since January 2017.But lets a bad actor bypass a safety check and write data directly into the page cache, the kernel's memory-based file buffer.
Second, a newer flaw in the rxkad_verify_packet_1() function from June 2023. This one does a similar dirty trick with a different code path.
Here's the kicker. Alone, neither bug works everywhere. One needs user namespaces, which some distros block. The other needs a kernel module that's not always loaded. But chain them together? Boom. Universal coverage. Every major Linux distro since 2017 falls.
Why Your Copy Fail Fix Didn't Actually Protect You
This one stings. A lot of us felt pretty good after blacklisting the algif_aead module for Copy Fail. It was the right move.
But Dirty Frag doesn't even touch that part of the kernel. It lives in totally different code, the xfrm and RxRPC subsystems. So that mitigation you carefully applied? Useless against this new threat.
As Kim put it in his disclosure: "Even on systems where the publicly known Copy Fail mitigation is applied, your Linux is still vulnerable to Dirty Frag."
Ouch. A real gut-punch for admins who thought they had their bases covered.
How Does the Attack Actually Play Out?
The elegance is terrifying. On a zero-copy send, splice() plants a reference to a memory page the attacker can only read into a critical kernel structure. Then, the kernel does its job, it runs some crypto on that page. Except it does it "in-place," modifying the memory directly.
So now the attacker has written to a page they should only be able to read. They can corrupt critical system files in memory—like /etc/passwd or /usr/bin/su. The kernel, and everything else on the system, now sees this "dirty," poisoned version.But exploit goes straight for /usr/bin/su. It overwrites the first 192 bytes of that setuid-root binary in memory with a tiny root-shell program. After that, a simple run of /usr/bin/su gives the attacker a root shell. No race conditions.Now crashes. It works on the first try. Every time.
Which CloudLinux Versions Are in the Crosshairs?
Per CloudLinux's own advisory, every supported version is vulnerable:
- CloudLinux 7h
- CloudLinux 8
- CloudLinux 9
- CloudLinux 10
The xfrm hole dates back to 2017. The RxRPC one to last year. Other confirmed victims include Ubuntu 24.04.4, RHEL 10.1, CentOS Stream 10, AlmaLinux 10, Fedora 44, and openSUSE Tumbleweed. Basically, any kernel up to 7.0.x.
Your Stopgap: Mitigate This Right Now
Don't wait for the patch. You need to block these modules immediately. Run this command:
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"What this does: It tells the kernel to never load esp4, esp6, or rxrpc. If they're already loaded, it kicks them out.
Fair warning: esp4 and esp6 are used by IPsec. Disabling them will break IPsec tunnels use the kernel's native data path. Do not apply this on hosts running IPsec, strongSwan, or Libreswan tunnels.
The rxrpc module is used by AFS clients. It's almost never on a standard web server, so blacklisting it is usually a no-op.
You're Not Done: Clean Up the Aftermath
Here's a step many admins miss. The exploit corrupts system files in memory. If a server was already hit, just applying the block isn't enough. You have to flush the poisoned data.
Force the kernel to reload the clean files from disk:
sudo echo 3 > /proc/sys/vm/drop_cachesThis drops the page cache, making the kernel re-read the real binaries from your drives.
Where Are the Real Patches?
CloudLinux is rolling fixes out in three waves:
Wave 1 — The CloudLinux Kernel (for CL7h & CL8)
Patched kernels are being built and tested now. They're based on the AlmaLinux 8 fix. Target versions and availability are coming soon.
Wave 2 — The AlmaLinux Kernel (for CL9 & CL10)
AlmaLinux is preparing the patch. Since CL9 and CL10 use the AlmaLinux kernel directly, the fix will hit their testing repo first before going live.
Wave 3 — KernelCare Livepatch (For Everyone)
KernelCare is building livepatches for all affected versions. Once it's out, your subscribed systems get it automatically. You can force it and check like this:
kcarectl --update
kcarectl --info | grep [CVE-ID]You'll see the CVE listed as patched in the output.
A Little Extra Armor for Imunify360 Users
CloudLinux found IOCs tied to a Bash script builds and runs the exploit. That script is already blacklisted in Imunify360. It's an extra layer of defense, not a replacement for patching, but it does buy you some time while the real fixes roll out.
Are You Actually Patched? How to Check.
Once you've updated and rebooted:
- Compare your kernel version to the expected version for your CloudLinux stream.
- Run
kcarectl --info | grep [CVE-ID]to see if the livepatch is active. - Keep an eye on the CloudLinux status page for live updates.
The Bigger, Scarier Picture
Dirty Frag is the third in a terrifying trend: page-cache manipulation bugs. Dirty Pipe, Copy Fail, now this. Different kernel parts, same ugly pattern—fooling the kernel into writing where it shouldn't.
The fact that this bug sat in the xfrm code since 2017 tells you everything about how complex modern kernels are. These aren't simple typos. They're deep, logical flaws in performance-optimized code that interact in ways no one foresaw.
For sysadmins, the lesson is clear. Apply the blacklist now. Watch for kernel and KernelCare updates like a hawk. And if you run Imunify360, be grateful for the extra net, but don't let it make you complacent.
The embargo broke before patches were ready. That's the messy reality. But CloudLinux is moving fast, and the mitigation works. Use it.
Sound off below: Have you applied the mitigation yet? What was your experience? And if you're still dealing with Copy Fail, check out our guide on CVE-2026-31431.
![Dirty Frag [CVE Pending]: How to Mitigate and Update Your CloudLinux Kernel Now](https://blogger.googleusercontent.com/img/a/AVvXsEgOUN592wKdAyrSc0UFUccCLvlAdeHQGTx1W2VRm94hP0aikglOIbJ0FXmUwoyO_fe-kAm17Cse8VS4vAhUGSmLHVyvnKyo9CXkP8psKPiqkpgpGM2nArA-85MbtBWFmDs-STqPVbSbIwoyvv6_4WwG9Y78XpV1Hkx137vOBm1MLWqeXKIkHSKLjEgy9kG8=w200-h200-p-k-no-nu)