The Linux kernel just can’t catch a break. Less than two weeks after the rather awkwardly named “Copy Fail” vulnerability (CVE-2026-31431) dropped into the public consciousness, another local privilege escalation (LPE) exploit has emerged. This one’s called “Dirty Frag,” and it was discovered by Hyunwoo Kim. The name sounds less like a security flaw and more like a questionable fast-food offering, but its impact is decidedly less appetizing.
Dirty Frag, like Copy Fail before it, allows a regular, unprivileged user to claw their way up to root privileges. The typical disclosure channels got a bit scrambled here; an unrelated third party apparently broke the embargo. So, no shiny CVE ID for this one. It just sort of… appeared.
The Two-Step Tango to Root
What makes Dirty Frag particularly interesting, and frankly, a bit alarming, is that it’s not just one simple bug. Oh no. This requires chaining two separate vulnerabilities. We’re talking about the xfrm-ESP Page-Cache Write and the RxRPC Page-Cache Write. The first lives in the IPsec ESP decryption paths, while the second skulks around in the RxRPC module.
Both have a similar DNA, though. The core issue? A zero-copy send path. When splice() decides to stick a reference to a page cache page into the frag slot of a sender-side skb— a page the attacker only has read access to — the receiver-side kernel code then proceeds to do in-place crypto magic on that very fragment. The result: the page cache of files you really shouldn’t be able to touch, like /etc/passwd or /usr/bin/su, get rewritten in RAM. Every subsequent read? It sees the modified copy. It’s like leaving your house keys with a particularly mischievous squirrel.
Not Copy Fail, But Cousin.
Dirty Frag and Copy Fail are definitely related. Think of them as siblings from the same kernel crypto family, but they were discovered by different researchers and live in different parts of the kernel’s sprawling codebase. Copy Fail messes with the algif_aead module in AF_ALG. Dirty Frag, on the other hand, goes straight for the ESP and RxRPC decryption fast paths. The table here lays out the distinctions, but the headline is this: both end up corrupting the page cache via kernel crypto operations. Different bugs, same nasty outcome.
| Factors | Copy Fail (CVE-2026-31431) | Dirty Frag |
|---|---|---|
| Kernel Subsystem | AF_ALG / algif_aead | xfrm ESP (esp4, esp6) and RxRPC |
| CVE Assigned | Yes (CVE-2026-31431) | No (embargo broken before allocation) |
| Controlled Bytes Written | 4 bytes | 4 bytes (per sub-vulnerability) |
| Chaining Required | No (single vulnerability) | Yes (two sub-vulnerabilities chained) |
| Discoverer | Theori (Research Team) | Hyunwoo Kim (@v4bel) |
| Public Disclosure Date | 29 April 2026 | 7 May 2026 |
Table 1:Comparison of Copy Fail and Dirty Frag
What’s particularly neat — and by neat, I mean terrifying — about Dirty Frag is how the two sub-vulnerabilities cover each other’s weaknesses. Neither the xfrm-ESP part nor the RxRPC part on its own is reliable enough for a full root escalation. But combine them? Bam. Immediate root on most Linux flavors. It’s like finding out your diet soda is actually 80 proof.
Why Should You Care (Besides the Obvious)?
Dirty Frag is more than just another CTF challenge fodder. Firstly, it affects a broad swathe of Linux distributions, with kernels going back to around 2017. Sound familiar? Copy Fail had a similar reach. Secondly, because that embargo broke prematurely, the exploit code is already out there. Publicly available exploit code for an LPE is never good news. Thirdly, the lack of a CVE ID means automated systems that track vulnerabilities by CVE might just sleep through this one. It’s a stealth bomber.
And if you’re running containers? That’s a whole other level of fun. An attacker could potentially use Dirty Frag to overwrite binaries in the base layer and then… escape to the host. So, yes, you should care.
Putting the Lid Back On
Patched kernels and live patches are apparently in the works and being tested. Good. Until then, if you’re not keen on waiting, there are mitigations. The most immediate one involves denylisting and unloading the vulnerable kernel modules: esp4, esp6, and rxrpc. You can do this by adding lines to /etc/modprobe.d/dirtyfrag-mitigation.conf.
But hold your horses. Denylisting esp4 and esp6 means no more IPsec ESP. If your VPN tunnels or encrypted comms rely on that, you’re going to have a bad time. Unloading rxrpc impacts services that depend on it, like AFS filesystems. So, before you go disabling things willy-nilly, understand the fallout. Assess the impact. Don’t be the admin who broke the internet while trying to fix a hole in the kernel.
Live patching is also an option where available. CloudLinux, for instance, is rolling out KernelCare live patches for affected versions. This means patching without a reboot, which is always a win. The advice, as always, is to patch early, patch often, and don’t assume your system is too obscure to be a target. Because clearly, it’s not.
🧬 Related Insights
- Read more: VECT 2.0: The Ransomware That Just Destroys, Not Encrypts
- Read more: Robinhood Account Flaw Fuels Phishing Frenzy
Frequently Asked Questions
What does Dirty Frag actually do? Dirty Frag is a local privilege escalation vulnerability in the Linux kernel that allows an unprivileged user to gain root access by chaining two related flaws in the IPsec ESP and RxRPC modules.
Will this affect my Linux distribution? It’s likely. Dirty Frag affects many major Linux distributions with kernels dating back to approximately 2017, similar to the recent Copy Fail vulnerability.
How can I fix Dirty Frag?
The primary mitigation is to update your kernel to a patched version as soon as it becomes available. Until then, you can denylist or unload the vulnerable kernel modules (esp4, esp6, rxrpc), but be aware of potential service disruptions.
