Dirty Frag turns a small kernel assumption into a root shell. 

At first glance, it looks like another member of the “Dirty” vulnerability family. But Dirty Frag deserves close attention because it is not a race-condition exploit like Dirty COW, and it is not simply a rerun of Dirty Pipe. It is a deterministic Linux local privilege escalation (LPE) that abuses two unrelated kernel subsystems to write attacker-controlled bytes into page-cache entries that the kernel still treats as read-only. 

Those two paths are: 

• xfrm-ESP, the IPsec ESP transform path, tracked as CVE-2026-43284  

• RxRPC, the Andrew File System RPC layer, tracked as CVE-2026-43500  

The public DirtyFrag write-up describes the vulnerability class as a chain of xfrm-ESP Page-Cache Write and RxRPC Page-Cache Write, capable of obtaining root privileges on major Linux distributions. It also states that Dirty Frag extends the bug class that includes Dirty Pipe and Copy Fail.  

Copy Fail showed that page-cache corruption did not end with Dirty Pipe. Dirty Frag pushes the same idea into different kernel territory. Systems that blocked Copy Fail by blacklisting algif_aead still face exposure because Dirty Frag does not depend on that module. The Dirty Frag author explicitly notes that Copy Fail motivated the research, and that the xfrm-ESP component shares the same sink as Copy Fail.  

The result is a Linux LPE class that is broad, reliable, and operationally uncomfortable. A low-privilege shell becomes enough to corrupt cached copies of files such as /usr/bin/su or /etc/passwd, then turn that corruption into root. 

Understanding Dirty Frag 

Dirty Frag abuses a dangerous mismatch between how the kernel handles zero-copy network sends and how some receive-side crypto paths perform in-place operations. 

The attacker first uses a vmsplice() and splice() chain to place controlled data into a pipe, then moves page-cache-backed data into a network socket through the MSG_SPLICE_PAGES shortcut. That shortcut lets the kernel transmit pages in place instead of copying them into a separate buffer. 

The flaw appears when the receive-side kernel code later performs in-place crypto on a frag entry inside struct sk_buff. If the attacker has arranged for that frag to point at a page-cache page for a read-only file, the crypto operation writes into the cached file page. The disk file remains read-only, but the cached copy in RAM changes. Every later read sees the modified version until the page cache is dropped or the host reboots. 

The core of Dirty Frag 

The attacker “dirties” the frag member of struct sk_buff, then uses the kernel’s own in-place write behavior to alter a file they should only read. 

The public proof of concept uses this primitive to target privileged files. In the xfrm-ESP exploit path, the Dirty Frag write-up describes replacing the first 192 bytes of /usr/bin/su in page cache with a small root-shell ELF payload. A later execve("/usr/bin/su") maps the corrupted cached copy, keeps the setuid-root bit behavior, and drops the user into a root shell.  

Unlike race-condition LPEs, there is no tiny timing window to win. The public repository describes Dirty Frag as a deterministic logic bug with no race condition requirement and a high success rate.  

Anatomy of the attack chain 

Dirty Frag begins with a simple attacker position: a low-privilege Linux shell. 

From there, the exploit builds a page-cache write primitive through two independent paths. The two primitives cover each other’s blind spots.  

The xfrm-ESP path provides a powerful arbitrary four-byte store, but it requires the ability to create a namespace. The RxRPC path avoids that namespace dependency, but depends on the rxrpc module being present. The public Dirty Frag FAQ explains that chaining both variants helps cover these distribution-specific gaps.  

Step 1: Plant a read-only page into the network path 

The attacker uses vmsplice() to place controlled bytes into a pipe. They then use splice() to move bytes from a read-only target file into the same pipe path, then from the pipe into a socket. Because the socket path uses MSG_SPLICE_PAGES, the kernel attaches page references rather than copying the data. 

Important note: One of those references points back to the page cache for a protected file. 

Step 2: Trigger in-place crypto 

In the xfrm-ESP path, the attacker reaches esp_input(). The vulnerable branch skips the expected skb_cow_data() copy-on-write protection and lets in-place crypto operate directly on the frag. 

In the RxRPC path, rxkad_verify_packet_1() performs an in-place decrypt on the first eight bytes of the RxRPC payload. 

Both paths create the same dangerous result: a write lands in a page-cache page that the attacker only had permission to read. 

Step 3: Corrupt a privileged target in memory 

During this step, the target is the cached copy, not the disk file. 

Dirty Frag demonstrates this by corrupting privileged files such as /usr/bin/su or /etc/passwd in page cache. For /usr/bin/su, the exploit writes a small root-shell ELF payload into the cached copy while the setuid-root behavior remains intact. The next execution reads the corrupted cached data and runs attacker-controlled code as root.  

For /etc/passwd, a later authentication-related read sees the modified cached content, creating another path to root. 

Step 4: Get root without a race 

The attack does not rely on repeatedly hammering a timing window. The Dirty Frag write-up states that each xfrm-ESP trigger stores exactly four bytes, the page-cache modification persists until drop_caches or reboot, and the operation is deterministic.  

This reliability is the key operational lesson. Many LPEs are noisy, brittle, or distribution-specific. Dirty Frag is different: once the required kernel path is available, the attack behaves more like a controlled write operation than a gamble. 

Step 5: Understand container exposure 

Containers share the host kernel. That means a vulnerable host kernel creates exposure across containerized workloads. 

Default Docker seccomp settings often block unprivileged unshare(CLONE_NEWUSER), which helps neutralize the xfrm-ESP path from inside a non-privileged container. But RxRPC does not depend on that namespace path. If the host exposes the RxRPC module and the container has access to AF_RXRPC sockets, the RxRPC path remains relevant. 

Privileged containers increase the risk further. Containers launched with options such as --privileged, --cap-add SYS_ADMIN, or --userns=host expose both paths more like a bare-metal host. 

Step 6: Mitigate at the module level 

The realistic immediate mitigation is module-level blocking. The Dirty Frag repository recommends removing and blocklisting esp4, esp6, and rxrpc, clearing the page cache, then updating once distributions backport fixes.  

That approach is especially important during the window between upstream patches and distribution-level availability. Kernel fixes take time to reach production fleets. Module-level mitigation gives defenders a practical control while patch management catches up. 

Dirty Frag and Copy Fail belong in the same conversation 

Dirty Frag is a little bit more than just similar to Copy Fail. It is another exploitation path for the same broader page-cache corruption class. 

A concise mental model helps: 

• Dirty COW: Race-based page-cache corruption  

• Dirty Pipe: Pipe-buffer page-cache overwrite  

• Copy Fail: AF_ALG crypto page-cache overwrite  

• Dirty Frag: xfrm/RxRPC page-cache overwrite  

Copy Fail uses AF_ALG, AEAD, and ESN-related crypto behavior to create a page-cache write primitive. Dirty Frag moves the idea into xfrm-ESP/IPsec and RxRPC. The xfrm-ESP component even shares the same sink as Copy Fail, according to the Dirty Frag author.  

For defenders, the connection changes the mitigation mindset.  

Important note: Blocking one subsystem does not end the class. A team that mitigates Copy Fail by blocklisting algif_aead still has Dirty Frag exposure if esp4, esp6, and rxrpc remain available. 

That is why these vulnerabilities belong together in training. They teach the same core lesson from different kernel angles: modern LPEs increasingly abuse legitimate zero-copy and in-place processing optimizations. Defensive teams need to recognize the pattern, not just the CVE.  

Dirty Frag mitigation guide 

CVE-2026-43284 (xfrm-ESP) was patched in upstream commit f4c50a4034e6 on 2026-05-08. CVE-2026-43500 (RxRPC) remains unpatched at the time of writing.  

On any kernel older than the xfrm-ESP fix, both paths are still reachable, so the realistic short-term mitigation is to prevent the vulnerable kernel modules from loading. If esp4, esp6, and rxrpc are not available, neither code path is reachable. 

Trade-offs 

• esp4 and esp6 implement IPsec ESP. Hosts that terminate or originate IPsec tunnels need them. 

• rxrpc implements Andrew File System (AFS) RPC. Hosts that do not mount AFS shares do not need it. 

For the typical desktop and most server workloads, neither module is needed at all. Blocklisting them is safe and reversible.  

A second, longer-term mitigation is to upgrade the kernel to one containing f4c50a4034e6, which closes the xfrm-ESP path; the RxRPC path still requires the blacklist until upstream ships a fix. 

Practice Dirty Frag and Copy Fail in free hands-on labs 

Dirty Frag and Copy Fail are the kind of vulnerabilities defenders need to experience, not just read about. They sit low in the stack, abuse trusted kernel behavior, and turn a local foothold into root through reliable page-cache corruption. 

Cyberbit offers two free hands-on labs to help you build that readiness. 

Dirty Frag (CVE-2026-43284/43500) Hands-on Lab 

Study how Dirty Frag chains its two primitives and run the public proof of concept on a vulnerable Ubuntu host to capture a flag from a privileged file. You will then examine how the attack would be detected on a hardened system and apply the realistic mitigation by blacklisting the vulnerable kernel modules. 

Copy Fail (CVE-2026-31431) Hands-on Lab 

In this lab, you will study the AF_ALG, AEAD, and ESN code paths that combine to make the bug exploitable, run the published proof of concept on a vulnerable Linux host to obtain a root shell, and review detection signals and mitigation paths that defend a real fleet against kernel-level privilege escalation. 

Practice both, understand the shared bug class, and give your team the operational confidence to respond before a local shell becomes a full compromise.