Dirty Frag (CVE-2026-43284 + CVE-2026-43500): the third page-cache write primitive in 13 months and what the pattern means for kernel security

Dirty Frag is two Linux kernel local privilege escalation vulnerabilities discovered and published by Hyunwoo Kim (@v4bel): CVE-2026-43284 (XFRM/ESP path) and CVE-2026-43500 (RxRPC/rxkad path). Both allow an unprivileged user to write 4 bytes at a controlled offset into the page cache of any readable file. The published exploit chains 48 such writes to overwrite the first 192 bytes of /usr/bin/su with shellcode, obtaining a root shell deterministically — no race conditions, no heap grooming, no ASLR bypass required. The patch for CVE-2026-43284 was merged on May 7, 2026.

The more significant fact is the class context. Dirty Frag is the third bug in the same vulnerability class in 13 months: Dirty Pipe (CVE-2022-0847) in March 2022, CopyFail (CVE-2026-31431) in April 2026, and now Dirty Frag in May 2026. All three share the same root cause — missing copy-on-write enforcement on splice()-based zero-copy paths where the kernel incorrectly allows in-place writes to frag pages that still reference the page cache. All three are exploitable by unprivileged users. The mitigations for each do not protect against the others: the CopyFail blacklist (algif_aead) does not protect against Dirty Frag's XFRM/ESP and RxRPC paths.

This is not a coincidence of timing. @v4bel is systematically auditing the kernel's zero-copy send path for missing CoW enforcement. Defenders should treat Dirty Frag as one member of an open class, not a bounded incident.

What we know

• CVE-2026-43284: XFRM/ESP path. esp_input() takes a fast path that performs in-place AEAD decryption on sk_buff frags when the skb is not cloned and has no frag_list. With the ESP + ESN + authencesn() combination, the decrypt writes 4 bytes (the high-order 32 bits of the sequence number) at an attacker-controlled offset. Authentication runs after the write — even when authentication fails the page cache write persists.
• CVE-2026-43500: RxRPC/rxkad path. rxkad_verify_packet_1 performs in-place single-block decryption using pcbc(fcrypt) on an sk_buff frag, through the same splice-based page cache pinning mechanism.
• Patch: CVE-2026-43284 patch merged to stable kernel on May 7, 2026 (71a1d9d). Sets the SKBFL_SHARED_FRAG flag on page frags arriving via splice, forcing the ESP fast path to call skb_cow_data() before in-place crypto.
• Public exploit: Weaponized exploit available at github.com/V4bel/dirtyfrag.

Root cause: the splice-to-skb-frag page cache write primitive

The fundamental mechanism is consistent across Dirty Pipe, CopyFail, and Dirty Frag. Understanding it once makes each new instance immediately recognizable.

When splice() moves data from a file descriptor into a pipe, and then from a pipe into a network socket, the kernel takes a zero-copy optimization: instead of copying the file's data into a new buffer, it plants a direct reference to the file's page cache page into the frag slot of the sending-side sk_buff. The kernel is correct to do this for read operations — the data is not modified. The bug appears when receiving-side code performs in-place cryptographic operations on that frag, assuming it owns the buffer. Since the frag still points to the original page cache page, the in-place write corrupts the page cache.

The kernel does not mark the corrupted page dirty. The on-disk file is unchanged. Standard file integrity tools that compare on-disk checksums will not detect the modification — the attack leaves no trace in the filesystem.

Each CVE in this class involves a different subsystem that performs in-place crypto on frags:

CVE-2026-43284: exploit chain detail

XFRM SA registration requires CAP_NET_ADMIN. The exploit obtains it by creating a user and network namespace via unshare(CLONE_NEWUSER | CLONE_NEWNET) — an unprivileged operation permitted on all major distributions by default unless kernel.unprivileged_userns_clone=0 is set.

With CAP_NET_ADMIN in the new namespace, the exploit:

1. Registers a XFRM SA with authencesn(hmac(sha256),cbc(aes)) and sets the target 4-byte value in XFRMA_REPLAY_ESN_VAL
2. Opens the target file (/usr/bin/su) and splices it into a pipe
3. Splices the pipe into a XFRM socket, triggering esp_input()
4. esp_input() performs in-place AEAD decrypt on the frag — writing 4 bytes at the controlled offset in the page cache of /usr/bin/su
5. Authentication fails and returns error; the write persists
6. Repeat 48 times with different offsets and values to write a complete root-shell ELF
7. Execute /usr/bin/su — the in-memory (page cache) version runs the injected shellcode

The entire chain is deterministic. Each of the 48 writes succeeds independently. There is no timing dependency, no heap state requirement, and no ASLR surface.

Why container environments are elevated risk

Page cache corruption is a shared-kernel attack. The page cache is not namespaced — it is global state on the host kernel. A process inside a container that obtains the page-cache write primitive can corrupt files on the host, not just within the container. The exploiting process needs to be able to splice a file that is page-cache-resident on the host — which is essentially any file that has been opened recently on the host.

If a container has even minimal host filesystem access (bind mounts, shared volumes), or if the target binary exists in the container image and is cached by the shared kernel, the escalation surface extends from container-root-to-host-root. This is why container environments should treat this vulnerability as a container escape risk, not just a local LPE.

What CopyFail mitigations do not cover

If your organization deployed the CopyFail (CVE-2026-31431) mitigation — specifically, blacklisting algif_aead or disabling AF_ALG socket support — that mitigation does not protect against Dirty Frag. The two bugs use entirely different code paths:

• CopyFail: AF_ALG socket → algif_aead.c → authencesn template write past boundary
• CVE-2026-43284: XFRM SA → esp_input() → ESP fast path without skb_cow_data()
• CVE-2026-43500: RxRPC → rxkad_verify_packet_1 → in-place pcbc(fcrypt)

The only shared dependency is unprivileged user namespace creation (for CVE-2026-43284). Restricting user namespaces blocks the ESP variant but not the RxRPC variant.

Affected configurations

• Any Linux kernel that includes CONFIG_INET_ESP (CVE-2026-43284) or CONFIG_AF_RXRPC (CVE-2026-43500) — both are compiled in on all major distribution kernels by default
• All major distributions are affected: Debian, Ubuntu, RHEL/CentOS, Fedora, SUSE, Arch, Alpine
• Cloud VMs (EC2, GCE, Azure) running distribution kernels — the cloud provider kernels follow distribution defaults
• Container hosts (Docker, Kubernetes) — shared kernel elevates the blast radius

Systems where kernel.unprivileged_userns_clone=0 are protected against CVE-2026-43284 specifically. The RxRPC variant (CVE-2026-43500) is separately limited by whether the rxkad module is loadable; on systems that have never loaded it, it is less immediately weaponizable.

Detection

Dirty Frag produces no filesystem events. The page cache write is not a file write — it is in-memory corruption of the kernel's cached file content. Standard detection approaches that do not apply:

• File integrity monitoring comparing on-disk checksums — the on-disk file is unchanged
• Audit rules for open() or write() on setuid binaries — neither syscall is used for the write

Detection requires syscall-level monitoring of the exploit chain:

• Monitor for splice() from a setuid binary file descriptor into a pipe into a network socket. This is the primitive. Legitimate processes do not splice setuid binaries into kernel crypto sockets.
• Alert on unshare(CLONE_NEWUSER | CLONE_NEWNET) followed by XFRM SA creation. The CVE-2026-43284 exploit requires this sequence. XFRM SA creation by a process that just created a new user namespace from an unprivileged context is anomalous in production environments.
• Monitor for rxrpc kernel module loads. CVE-2026-43500 requires the RxRPC module. Unexpected module loads from unprivileged contexts are detectable via kernel_module_load agent events.
• Datadog Workload Protection: The CopyFail Content Pack (CVE-2026-31431 Copy Fail Exploit) covers the splice()-from-setuid-binary primitive that Dirty Frag also uses. Enable it if not already active (requires Datadog Agent 7.68+, ships disabled).

Remediation

1. Apply kernel patches. The CVE-2026-43284 fix is in stable kernel as of May 7, 2026 (commit 71a1d9d). Update to a kernel version containing this commit. Distribution-specific patched kernels will follow vendor advisory timelines.
2. Restrict unprivileged user namespaces. On Debian and Ubuntu: sysctl -w kernel.unprivileged_userns_clone=0. On other distributions: sysctl -w user.max_user_namespaces=0. This blocks the CVE-2026-43284 exploit path. Note: this breaks some legitimate functionality (rootless containers, Chrome sandboxing) — assess impact before deploying fleet-wide.
3. Prioritize container hosts. The shared-kernel escalation path from container to host makes container environments the highest-priority patch targets. An unprivileged user in a container becomes a full host root via Dirty Frag.
4. Do not rely on CopyFail mitigations. If you deployed algif_aead blacklisting or AF_ALG disable after CopyFail, those controls do not protect against Dirty Frag. Independent remediation is required.

Class analysis: the third bug in 13 months

Dirty Pipe (March 2022) was attributed to a single researcher (Max Kellermann) who found it during routine log file corruption debugging. CopyFail (April 2026) and Dirty Frag (May 2026) are both attributed to Hyunwoo Kim (@v4bel), published one month apart. Both target sk_buff frags rather than pipe pages. The inference is that @v4bel is systematically surveying kernel subsystems that perform in-place operations on frags received via splice(), looking for cases where skb_cow_data() is missing or bypassable.

The defensive implication is not just "patch Dirty Frag." It is: the same root cause audit has now found two bugs in the XFRM and RxRPC subsystems. Additional subsystems that receive frags from splice() and perform in-place operations without consistent CoW enforcement may also be vulnerable. The kernel's patch for CVE-2026-43284 introduces the SKBFL_SHARED_FRAG flag specifically to make this class of check auditable. Distributions should expect additional CVEs in this class until the kernel's zero-copy send paths are audited comprehensively for the missing-CoW pattern.