Why, you DirtyFrag!

By Chris Williams

Hot on the heels of Copy Fail, here comes another Linux kernel root-escalation vulnerability. As always, this is not a slam on the kernel developers as OSdev is hard and often a thankless task. And Windows has its fair-share of equivalent bugs, so these kinds of holes are not a Linux-specific issue. But two points spring to mind:

One is that this is a really neat exploit. You basically trick the kernel into allowing you to scribble over in-memory copies of normally read-only files, so that for all intents and purposes, you can modify them, and bend them to your will. If those files can grant you complete control of the machine, then you have a root-privilege escalation vulnerability.

The other point is that this was supposed to be disclosed on May 12, 2026. It was discovered by Hyunwoo Kim, and privately reported so that the kernel developers and Linux distributions could have their patches ready in time for the disclosure.

However, at least one person saw the patch in the open-source kernel tree, figured it was closing a root-privilege escalation vulnerability, and blogged about it not knowing there was an embargo on disclosure. That led to Kim publicly documenting the technique, now known as DirtyFrag, ahead of the intended disclosure date.

To me that's the headache with open source: the preparation for disclosure is at times out in the open, so while we benefit from the transparency, it also means that security bugs are disclosed as the patch is being developed and distributed. Which is pain for those managing the security of shared and public-facing systems. I'm personally all for open source, but this is all an interesting trade-off to consider.

I was first to report the CPU-level Meltdown vulnerability in January 2018 because I saw over the Christmas period leading up to that, open-source kernel developers were reworking MMU-level code that ordinarily doesn't need to be touched, revealing that there was a processor-level side-channel vulnerability that could leak secrets and other data from memory that wasn't supposed to be accessible. And that's the kind of thing that is tough to hide in open source.

Patches for DirtyFrag are making their way to users; update your systems, or use short-term mitigations.

IMHO...

One final thing before my analysis of the bugs: check out Zero Day Clock. According to the data it has processed, and if correct, the time from disclosure of a computer security vulnerability to exploitation has plummeted. There are lots of reasons why, from autonomous AI to supply-chain attacks to financial incentives.

This collapse of disclosure-to-exploitation time represents a fundamental shift in, for want of a better term, the adversarial lifecycle. When I spotted the early signs of Meltdown, it required a human eye to notice unusual churn in low-level code and connect the dots. While still today there are folks who scrutinize source code commits for such things, as we saw with DirtyFrag, that manual intuition is being augmented or replaced by automated pipelines that treat every public commit like a blueprint for an exploit.

We have moved from a world where defenders had weeks to coordinate, to one where the window of exposure is often measured in hours from the moment a fix hits a public repository. In the open-source model, the very act of healing the code now serves as a flare for those looking to wound its users, creating a race where the defender must be perfect, but the attacker only needs to be fast.

My technical summary

DirtyFrag is a pair of Linux kernel security vulnerabilities that can be exploited alongside each other to achieve root-level privilege escalation. Someone can use this technique to go from a normal user to root user, and take over the system.

This is done by abusing zero-copy networking paths to modify the page cache of read-only files in RAM. The two distinct bugs are: a 4-byte arbitrary write in the xfrm-ESP subsystem (CVE-2026-43284) and an 8-byte brute-forced write in the RxRPC stack (CVE-2026-43500).

The core primitive

In exploiting each bug, an attacker uses the splice system call to plant a reference to a page cache page, which the attacker only has read access to, into the frag list of a nonlinear socket buffer (sk_buff).

When the kernel later processes this sk_buff through a path that performs in-place cryptographic operations (where the source and destination buffers are identical), it writes directly onto the mapped file page. This bypasses the typical copy-on-write (CoW) protections because the kernel erroneously assumes the buffer is private or fails to check if the underlying fragment is shared with the page cache.

The overall result is that an attacker can deterministically overwrite bytes in read-only files with attacker-chosen data. For example, if the target file is /etc/passwd, an attacker can gain root-level privilege escalation by crafting a root-level account entry with an empty password, and then running the su command as an unprivileged user to gain root access.

Exploit step-by-step: xfrm-ESP (CVE-2026-43284)

This primary method of exploitation provides a deterministic 4-byte arbitrary write primitive but requires CAP_NET_ADMIN (typically obtained via a user namespace).

  1. The attacker creates a new user and network namespace (CLONE_NEWUSER | CLONE_NEWNET) to gain the necessary privileges for XFRM state management.

  2. An XFRM state is registered using the authencesn algorithm, allowing the attacker to specify a 32-bit value in the Extended Sequence Number (ESN) field via the XFRMA_REPLAY_ESN_VAL attribute. While the ESN is typically used in the authentication header, it is processed here in a way that allows this 32-bit value to serve as a 4-byte arbitrary write payload.

  3. The attacker uses vmsplice to load an ESP header into a pipe, followed by splice to map 16 bytes of a target file into the same pipe.

  4. The pipe is spliced into a UDP socket; over loopback, the kernel receives the packet and routes it to esp_input.

  5. In esp_input, the kernel checks if the skb is cloned or has a frag_list. If it is a simple nonlinear skb with fragments but no frag_list, it jumps to the skip_cow label, leaving the attacker-pinned page cache page in the fragment list.

  6. The crypto_authenc_esn_decrypt function prepares for decryption by moving high-order sequence bits, performing a scatterwalk_map_and_copy to the destination buffer. Since the source and destination are identical, the attacker-controlled ESN value is written directly into the target file's page cache.

  7. By repeating this process across different offsets, the attacker can overwrite arbitrary bytes in a target file. Because the ESP primitive is deterministic and can write larger chunks of data across multiple offsets more easily than the RxRPC variant, it is frequently used to overwrite setuid-root binaries (like /usr/bin/su or pkexec) with a small ELF stager to gain immediate root access.

Exploit step-by-step: RxRPC (CVE-2026-43500)

This secondary vulnerability acts as a fallback for the primary ESP exploit, providing an 8-byte write primitive that does not require namespace privileges but involves brute-forcing a cryptographic key.

  1. In user space, the attacker calculates a session key K such that fcrypt_decrypt(Ciphertext, K) yields a desired plaintext, for example an entry in /etc/passwd. fcrypt is an Andrew File System dedicated 64-bit block cipher based on DES, and its 56-bit keys can be brute-forced relatively quickly on modern hardware or via precomputed tables, making this a viable "namespace-less" path.

  2. The attacker registers an RxRPC token, using the add_key system call, containing the chosen session key.

  3. Similar to the ESP variant, splice() is used to plant 8 bytes of the target file into an sk_buff fragment.

  4. An AF_RXRPC client initiates a call, and a fake UDP server responds with a CHALLENGE to establish a security context using the attacker's key K.

  5. The attacker responds with a DATA packet; when the client calls recvmsg, the kernel reaches rxkad_verify_packet_1, which performs in-place pcbc(fcrypt) decryption on the first 8 bytes of the payload.

  6. Because the fragment points to the page cache and the skb is not properly isolated, the decryption result is written back into the file page in RAM.

  7. Since one 8-byte write may not be enough to reach a delimiter, the exploit performs multiple writes using "last-write-wins" logic, correcting for previous modifications during the brute-force step.

Paired for reliability

The two bugs are paired to maximize Linux distribution coverage. The ESP variant is preferred for its deterministic nature and ability to write large payloads (like an ELF binary) 4 bytes at a time. If user namespaces are restricted (for example, by AppArmor on Ubuntu), the exploit falls back to the RxRPC variant. While RxRPC is limited by the brute-force cost and the rarity of the rxrpc.ko module on some enterprise builds, it is often present and accessible on desktop distributions where namespaces are hardened.