Thoughts on Dirty Frag
On May 7, 2026, Hyunwoo Kim (@v4bel) publicly disclosed a new Linux kernel vulnerability class dubbed Dirty Frag. The disclosure chains two CVEs, CVE-2026-43284 (xfrm-ESP Page-Cache Write) and CVE-2026-43500 (RxRPC Page-Cache Write), to achieve universal local privilege escalation across every major distribution.
The embargo was broken by external factors before patches existed, and the document was published at the request of the linux-distros maintainers.
Dirty Frag is a direct descendant of Dirty Pipe and Copy Fail. All three belong to the same bug class: they exploit logic flaws in how the kernel handles page-cache references to write arbitrary data into read-only files. Like its predecessors, Dirty Frag is deterministic. No race condition, no heap spray, no kernel-specific offset table. You compile it, you run it, you get root. The kernel doesn't even panic if it fails.
xfrm-ESP variant gives you a powerful 4-byte STORE primitive by dirtying the frag member of struct sk_buff, and it works on most distributions — but it needs namespace privileges, which Ubuntu's AppArmor sometimes blocks. The RxRPC variant doesn't need namespaces at all, but the rxrpc.ko module only ships on Ubuntu. By combining the two, you get a one-liner that roots Ubuntu, RHEL, Fedora, openSUSE, CentOS Stream, and AlmaLinux alike. That's it...
What strikes me the most is how long these bugs sat in the kernel.
CVE-2026-43284 traces back to a commit from January 2017. CVE-2026-43500 goes back to June 2023. That's a 9-year window for the older one. The xfrm-ESP path shares the same sink as Copy Fail but fires regardless of whether algif_aead is loaded, meaning the existing Copy Fail mitigation (blacklisting algif_aead) did ABSOLUTELY nothing to prevent Dirty Frag.
Mitigation
To mitigate, you can blacklist the three modules (esp4, esp6, rxrpc) and flush the page cache, but really you want the patches: f4c50a4034e6 for CVE-2026-43284 and aa54b1d27fe0 for CVE-2026-43500.
[^1] https://github.com/V4bel/dirtyfrag
[^2] https://www.openwall.com/lists/oss-security/2026/05/07/8
#blog #cybersecurity #dirtyfrag #infosec #linux