Dirty Frag Gave Root Before Anyone Had a Patch

On May 7, an unrelated third party published a working exploit for one half of a Linux kernel privilege escalation chain that researcher Hyunwoo Kim had reported to kernel maintainers a week earlier, on April 30. The coordinated disclosure process — the thing that's supposed to give distributions time to prepare patches before the exploit goes public — collapsed in real time.

Kim responded within hours by releasing the complete exploit, which he named Dirty Frag. Both CVEs. Full proof-of-concept. Root on every major distribution he tested: Ubuntu 24.04, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44. No race condition. No special permissions. One command.

No distribution had a kernel patch ready.

How It Works

Dirty Frag chains two page-cache write primitives in different Linux kernel networking subsystems. The first, CVE-2026-43284, lives in the ESP modules — esp4 and esp6 — that handle Encapsulating Security Payload processing for IPsec. The second, CVE-2026-43500, lives in the RxRPC module that supports the Andrew File System protocol.

The underlying bug is in how both subsystems handle in-place decryption. When the receive path processes encrypted data carried in paged buffers — the kind of memory-mapped pages that the kernel uses for file-backed I/O — it decrypts the ciphertext directly over the original pages. This is fine when the kernel exclusively owns those pages. It's a root exploit when it doesn't.

The attack works by using splice(2) or sendfile(2) to pass pipe pages into the socket layer. These system calls attach memory pages to socket buffers without the kernel taking private ownership of those pages. When ESP or RxRPC then runs its decryption pass over those buffers, the plaintext result overwrites memory that's shared with the page cache — the kernel's central mechanism for caching file contents.

The practical result: an unprivileged user can write controlled bytes into the page cache of any readable file on the system. The ESP primitive (CVE-2026-43284) gives a 4-byte STORE into the page cache. The RxRPC primitive (CVE-2026-43500) provides the ability to create the necessary user namespace. Chain them together, and you can modify critical system files — /etc/passwd, PAM configuration, setuid binaries — without any of the permission checks that are supposed to prevent exactly this.

There is no race condition involved. Unlike Dirty Cow, which required winning a race between mmap and madvise, Dirty Frag's page-cache write is deterministic. You send the right data through the right system calls, and the write lands reliably. Every time.

The Disclosure Failure

I want to be clear about what happened with the disclosure, because the narrative matters.

Kim reported both vulnerabilities to the Linux kernel security team on April 30, 2026. This is the correct process. You report privately, the maintainers develop patches, distributions integrate those patches, and the public disclosure happens after users have had time to update. This process has worked, more or less, for decades.

On May 7, someone unrelated to Kim's disclosure independently published the ESP exploit — CVE-2026-43284 — publicly. It's not clear whether this was independent discovery, a leak from the embargo process, or something else. What is clear is that once half the chain was public, the coordinated disclosure was dead. Kim released the full Dirty Frag exploit the same day, with distribution maintainers' agreement, via oss-security.

The upstream patch for the ESP component was merged into the netdev tree on May 7. As of today, May 9, the upstream patch for the RxRPC component is still pending. AlmaLinux and CloudLinux have shipped kernel updates addressing the ESP half. Most major distributions — Ubuntu, RHEL, Fedora, openSUSE — are still working on it.

A fully functional root exploit has been publicly available for two days, and a complete patch doesn't exist yet.

The "Dirty" Lineage

Linux kernel page-cache vulnerabilities have a naming tradition at this point. Dirty Cow (CVE-2016-5195) exploited a race condition in copy-on-write memory handling. Dirty Pipe (CVE-2022-0847) abused pipe buffer flags to overwrite page-cache pages through a pipe splice. Copy Fail (CVE-2026-31431), disclosed just weeks ago, targeted the algif_aead cryptographic interface in the kernel's crypto subsystem.

Dirty Frag is the fourth entry. Same fundamental attack surface — the page cache — but a completely different entry point. Instead of pipes, copy-on-write, or the generic crypto API, it goes through the IPsec ESP decryption path and the RxRPC protocol handler.

There's an uncomfortable pattern here. Each of these vulnerabilities exploits the fact that the Linux kernel has multiple code paths that can write to page-cache-backed memory without properly verifying ownership. Dirty Cow was patched. Dirty Pipe was patched. Copy Fail was patched. Dirty Frag is being patched. But the broader question — how many other kernel subsystems have decryption or transformation paths that operate on externally-backed pages? — doesn't have an answer.

The ESP code that contains CVE-2026-43284 was committed in January 2017. Nine years. Nobody caught it. This wasn't obscure code. ESP is the core encapsulation protocol for IPsec — it's loaded on every system that uses kernel-level VPN tunnels, and it can be auto-loaded by any unprivileged user who opens the right kind of socket.

Why This Is Worse Than the Headlines Suggest

Dirty Frag is a local privilege escalation. You need code execution as an unprivileged user first. On paper, that limits the blast radius.

In practice, it doesn't.

Microsoft's security team published a blog on May 8 documenting active exploitation of Dirty Frag in the wild. The attack pattern they observed: an attacker gains SSH access to a Linux host via stolen credentials, drops a compiled ELF binary implementing the Dirty Frag chain, elevates to root, and then modifies the GLPI IT asset management system's LDAP authentication files. They're not just getting root — they're using root to backdoor infrastructure management tools.

Container environments are in scope. Dirty Frag operates at the kernel level, which means container isolation doesn't protect you — a compromise in any container that can create the necessary sockets can escalate to host root. There's one important caveat: default seccomp profiles in Kubernetes block the system calls needed for the xfrm exploit chain. Juliet Security tested Dirty Frag against EKS, GKE, and Talos clusters and found that RuntimeDefault seccomp denied the unshare(USER|NET) call required to set up the exploit namespace. If your Kubernetes pods run with custom seccomp profiles — or worse, with securityContext.seccompProfile.type: Unconfined — you're exposed.

This lands at a moment when Mandiant's M-Trends 2026 report documented that mean time-to-exploit has gone negative — attackers are routinely deploying exploits before vendors ship patches. Twenty-eight percent of CVEs exploited within 24 hours of disclosure. Dirty Frag is a textbook case. The exploit existed in the wild before any distribution had a fix. The window between "vulnerability known" and "patch available" isn't a buffer anymore. It's a countdown that starts at zero.

What to Do

Blacklist the vulnerable modules immediately. Create /etc/modprobe.d/dirtyfrag.conf with:
```
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
```
Then run rmmod esp4 esp6 rxrpc 2>/dev/null to unload them if currently loaded. Regenerate your initramfs afterward. AWS also recommends blacklisting ipcomp4 and ipcomp6 as defense-in-depth.
Check whether you actually use IPsec. If you terminate IPsec tunnels on this host, blacklisting esp4/esp6 will break them. The mitigation isn't free for everyone. If you run site-to-site VPN tunnels through the kernel's xfrm stack, you need the kernel patch, not the module blacklist. For these hosts, restrict network access and monitor aggressively until patches ship.
Restrict user namespaces if possible. Set sysctl -w user.max_user_namespaces=0 on hosts that don't need them. The Dirty Frag PoC uses user namespaces to set up the exploit environment. Disabling them blocks this path — but it will also break unprivileged containers, Flatpak, and some browser sandboxes. Know what depends on user namespaces before you flip this.
Audit your Kubernetes seccomp profiles. If any pods run with Unconfined seccomp, they can potentially exploit Dirty Frag for container-to-host escalation. Switch to RuntimeDefault or a custom profile that blocks unshare, socket(AF_KEY), and the relevant setsockopt calls.
Lock module loading on production servers. sysctl -w kernel.modules_disabled=1 prevents any new kernel modules from loading until reboot. This is aggressive — it prevents legitimate module loading too — but on servers with a stable module set, it eliminates the risk of an attacker triggering auto-load of esp4/esp6.
Monitor for the upstream RxRPC patch. The ESP patch (CVE-2026-43284) is in mainline. The RxRPC patch (CVE-2026-43500) is still pending. Until both are merged and your distribution ships an updated kernel, you're relying on mitigations, not fixes.

What Nobody Wants to Say

Hyunwoo Kim did everything right. He reported responsibly. He gave maintainers a week. The process failed anyway, because coordinated disclosure assumes the information stays contained — and sometimes it doesn't.

The kernel security team isn't at fault either. Seven days is fast for kernel patch development, especially for a vulnerability that touches the networking stack. The patches were in progress. The timeline was reasonable.

The problem is structural. The Linux kernel has millions of lines of code across hundreds of subsystems, many of which perform in-place transformations on memory that may or may not be privately owned. Dirty Cow, Dirty Pipe, Copy Fail, and now Dirty Frag are all instances of the same fundamental problem: the kernel's trust model for page ownership has too many blind spots.

Four different page-cache write vulnerabilities in ten years. Each found by a different researcher, in a different subsystem, using a different technique. The pattern isn't that researchers are clever — they are — it's that the attack surface keeps producing the same class of bug.

I don't know what the fifth one will be called. But at this point, I'd be surprised if we don't find out.

Sources: BleepingComputer, The Hacker News, Ubuntu Security Blog, Microsoft Security Blog, Wiz Blog, Juliet Security, AWS Security Bulletin, Phoronix