Dirty Frag: A Technical Breakdown of the Universal Linux Privilege Escalation Vulnerability

The Linux ecosystem is currently mitigating a highly critical vulnerability class known as “Dirty Frag.” Comprising two distinct Common Vulnerabilities and Exposures (CVE-2026-43284 and CVE-2026-43500), this deterministic logic flaw permits an unprivileged local user to escalate their system access to full administrative, or “root,” privileges. Discovered by security researcher Hyunwoo Kim and publicly disclosed in May 2026, the vulnerability impacts nearly all major Linux distributions, including Ubuntu, Red Hat Enterprise Linux (RHEL), Fedora, AlmaLinux, and CentOS.

Dirty Frag carries a Common Vulnerability Scoring System (CVSS) v3.1 score of 7.8 (High). The score reflects that while the attack requires local execution capabilities, it demands low complexity, requires zero user interaction, and completely compromises system confidentiality, integrity, and availability. Unlike traditional vulnerabilities that rely on unreliable race conditions or specific memory offsets, Dirty Frag exploits fundamental architectural optimizations within the Linux kernel’s networking and cryptographic subsystems, resulting in a near-guaranteed exploit success rate without causing kernel panics.

The Foundation: Understanding Page Cache Corruption

To fully grasp the mechanics of Dirty Frag, it is essential to understand the Linux page cache—the underlying system component that the vulnerability corrupts.

Operating systems utilize the physical memory (RAM) to cache data read from slower storage devices, such as hard drives or solid-state drives. When an application reads a file, the Linux kernel’s Virtual File System (VFS) loads that file’s data into memory in blocks known as “pages”. This is the page cache. If another application requests the same file, the kernel serves it directly from the lightning-fast RAM cache rather than reading it from the disk again.

Because the page cache is a globally shared resource, a single in-memory copy of a system file (like a system utility or configuration file) serves all users. Security mechanisms normally prevent unprivileged users from writing data directly into the page cache of files they do not own. If a user does have permission to modify a file, the kernel marks the modified memory page as “dirty,” signaling to the operating system that the changes must eventually be written back to the physical disk to ensure persistence.

However, if an attacker can exploit a kernel bug to write data into the page cache without the kernel marking the page as dirty, they can alter the behavior of the operating system entirely in memory. The file on the physical disk remains completely untouched, bypassing traditional file integrity monitoring solutions that check disk-based cryptographic hashes.

The Evolution of Page Cache Vulnerabilities

Dirty Frag is not an isolated phenomenon; it represents the culmination of a specific vulnerability class that targets the page cache. Tracing the history of these bugs provides critical context for how Dirty Frag operates.

Dirty COW demonstrated that the Copy-on-Write (COW) mechanism—which creates a private copy of shared memory only when a modification is attempted—could be bypassed via a race condition. Dirty Pipe refined this by manipulating inter-process communication pipes to cleanly overwrite the page cache.

The direct predecessor to Dirty Frag, known as Copy Fail, shifted the attack surface to the Linux kernel’s cryptographic subsystem. Discovered by researchers at Theori just days before Dirty Frag, Copy Fail exploited the authencesn algorithm within the algif_aead module. By manipulating how the kernel handled input and output data structures during encryption, an attacker could force the kernel to write four controlled bytes of data directly into the shared page cache of any readable file on the system. Dirty Frag shares the exact same “sink”—the ultimate mechanism of memory corruption—as Copy Fail, but triggers it through entirely different, unpatched networking pathways.

Networking Infrastructure: Socket Buffers and Zero-Copy

Dirty Frag leverages how the Linux kernel handles high-performance data transfers over networks. When network data is processed, it is stored in a complex kernel data structure known as the socket buffer, or sk_buff.

Historically, an sk_buff contained a single, continuous block of linear memory. However, modern high-speed networks require the transmission of massive amounts of data. Allocating massive contiguous blocks of memory for every single network packet creates immense processing overhead and leads to memory fragmentation. To solve this, kernel developers introduced “nonlinear” socket buffers.

A nonlinear sk_buff consists of a small linear header and an array of external memory pointers called “fragments” (represented in the code as skb_frag_t). Instead of containing the data directly, these fragments point to specific memory pages located elsewhere in the system’s RAM.

The Splice System Call

To maximize system performance, Linux utilizes a concept called zero-copy networking. When an application wants to send a file over a network, a traditional operating system must copy the file from the disk into the kernel’s page cache, copy it again into the application’s user-space memory, and copy it a third time back into the kernel’s networking socket buffers.

Linux circumvents this massive inefficiency through the splice() system call. splice() allows data to be moved directly between two file descriptors entirely within the kernel, bypassing user-space applications completely. When an attacker uses splice() to send a file into a network socket, the kernel simply creates a nonlinear sk_buff and populates the fragments (skb_frag_t) with direct pointers to the page cache where the file already resides.

This zero-copy optimization is critical to the vulnerability: it directly links a network transmission buffer to the globally shared page cache of a system file.

The Root Cause: Bypassing Copy-On-Write via Fast Paths

The protective boundary separating network buffers from shared system memory is the Copy-on-Write (COW) mechanism. Under normal circumstances, if the kernel networking stack needs to modify the data inside a socket buffer that contains fragments pointing to externally owned memory (such as a page cache entry attached via splice()), the kernel must allocate new, private memory and copy the data over before making any changes.

Dirty Frag exists because specific cryptographic “fast paths” in the kernel bypass this vital COW safety check.

To maximize the speed of encrypted network protocols, kernel engineers implemented “in-place decryption” optimizations. Rather than copying encrypted network data into a new memory location before decrypting it, the kernel decrypts the data mathematically and writes the resulting plaintext directly over the original ciphertext, utilizing the exact same memory buffer.

The flaw resides in the in-place decryption fast paths of the esp4, esp6, and rxrpc kernel modules. When a socket buffer carrying paged fragments attached via splice() reaches these receive paths, the kernel executes the decryption directly over the externally-backed pages without verifying memory ownership. Because the memory being overwritten is actually a shared page cache entry for a system file, the file is silently and permanently corrupted in memory.

Variant 1: The xfrm-ESP Vulnerability (CVE-2026-43284)

Dirty Frag is actually composed of two distinct attack vectors, bundled together by the exploit author to ensure it functions across the widest possible range of Linux distributions.

The first variant targets the esp4 and esp6 modules, which are part of the kernel’s xfrm subsystem. This subsystem handles IPsec (Internet Protocol Security), a widely used protocol suite for securing internet communications through authentication and encryption. ESP stands for Encapsulating Security Payload, the specific IPsec protocol responsible for providing confidentiality.

The root cause of this specific vulnerability was introduced into the Linux kernel codebase in January 2017.

The Exploit Chain

To trigger the ESP variant, an unprivileged attacker executes a precise sequence of system calls:

1. Cache Acquisition: The attacker opens a standard data pipe and uses the vmsplice() system call. This attaches a target memory page—specifically, a page belonging to a highly privileged system file like /usr/bin/su—into the pipe as a memory fragment.

2. Cryptographic Preparation: The attacker interfaces with the AF_KEY socket family or the XFRM netlink interface to establish a Security Association (SA). This tells the kernel which cryptographic cipher and encryption key to use for upcoming network traffic.

3. Data Injection: Using the splice() system call, the attacker moves the paged fragment from the pipe into a UDP network socket that has been configured for ESP encapsulation.

4. The Trigger: The attacker sends a carefully crafted, malicious ESP network datagram to the local machine’s loopback address.

5. In-Place Corruption: As the kernel processes the received UDP packet, it routes it through the ESP-in-UDP MSG_SPLICE_PAGES fast path. Failing to enforce COW protections, the kernel decrypts the attacker’s datagram directly over the spliced page cache entry.

The Namespace Hurdle and AppArmor

While the ESP variant is highly reliable, it features a significant prerequisite constraint: configuring an XFRM Security Association typically requires high-level system permissions, specifically the CAP_NET_ADMIN capability.

Standard users do not possess this capability. To bypass this restriction, an unprivileged attacker must instruct the kernel to create a new “user namespace” and “network namespace”. Namespaces are a Linux feature that isolates system resources, forming the foundation of containerization technologies like Docker and Kubernetes. When a user creates a new, isolated namespace, they are granted administrative capabilities exclusively within that artificial environment, satisfying the CAP_NET_ADMIN requirement.

However, many security-focused Linux distributions actively restrict namespace creation. Ubuntu, for example, utilizes a Mandatory Access Control (MAC) system called AppArmor. Default AppArmor configurations frequently block unprivileged users from generating new namespaces. Consequently, the ESP variant of Dirty Frag is effectively neutralized on default Ubuntu installations, as the attacker cannot acquire the permissions needed to configure the cryptographic fast path.

Variant 2: The RxRPC Vulnerability (CVE-2026-43500)

To achieve true universality and bypass the AppArmor restrictions found on systems like Ubuntu, the exploit authors incorporated a second vulnerability variant residing in the rxrpc.ko module.

RxRPC is a network transport protocol primarily utilized to support the Andrew File System (AFS), a distributed file system designed for wide-area networks. In June 2023, the Linux kernel developers updated the RxRPC module, inadvertently introducing the exact same in-place decryption fast-path optimization flaw that existed in the ESP module.

Bypassing Namespace Restrictions

The strategic advantage of the RxRPC variant is that it does not require the attacker to configure complex network policies. Therefore, it entirely bypasses the need for CAP_NET_ADMIN privileges or the creation of user namespaces.

To exploit this variant, the attacker opens an AF_RXRPC socket and interacts with the kernel’s key retention service using the add_key() system call to register an rxkad session key. They then utilize the same splice() primitive to map the target page cache to the socket buffer. When data is received, the RxRPC path decrypts the payload directly into the shared page cache, achieving the same memory corruption as the ESP variant without triggering AppArmor’s namespace defenses.

While highly effective on Ubuntu—where the rxrpc.ko module is compiled and loaded by default—this variant encounters friction on enterprise distributions like Red Hat Enterprise Linux (RHEL) 10.1, which often do not include or load the niche RxRPC module by default.

By combining both vulnerabilities, the exploit guarantees success across varying environments. On distributions that permit namespaces (like RHEL or Fedora), the ESP variant executes the attack. On distributions that block namespaces but load RxRPC (like Ubuntu), the RxRPC variant takes over, creating a comprehensively universal exploit chain.

Payload Delivery: Binary Injection vs. Key Brute-Forcing

A critical complexity in exploiting Dirty Frag is the nature of the memory overwrite. In standard buffer overflow attacks, the malicious actor simply writes their exact executable code (shellcode) directly into the target memory. However, because Dirty Frag uses the kernel’s cryptographic decryption routines as the overwrite mechanism, the attacker does not have direct, straightforward control over the plaintext that is written into the page cache.

The attacker controls the encrypted ciphertext and the cryptographic key. The kernel mathematically decrypts the ciphertext using the key, and the resulting plaintext is what overwrites the file in memory. To successfully exploit the system, the attacker must manipulate the cryptography so that the resulting plaintext perfectly translates into functional system commands.

The ESP Approach: Injecting the 192-Byte Stub

When executing the ESP variant, the attacker configures the IPsec Security Association with specific parameters to ensure the decryption yields a precise 192-byte sequence of x86_64 assembly code.

The target of this overwrite is typically a setuid-root binary, such as /usr/bin/su. Setuid (set user ID) binaries are executable files that temporarily grant the user running them the permissions of the file’s owner—in this case, the root administrator.

The attacker splices a memory page of the /usr/bin/su executable into the socket and triggers the vulnerability. The in-place decryption overwrites a section of the executable’s machine code with the 192-byte payload. This specific payload is a “stub” composed of assembly instructions designed to execute the system calls setuid(0) (setting the user ID to root), setgid(0) (setting the group ID to root), and finally execve("/bin/sh") (launching a command-line shell).

When the attacker subsequently types su in their terminal, the kernel executes the newly corrupted binary straight from the page cache. Because the binary retains its setuid properties, the injected assembly instructions are executed with maximum system privileges, immediately dropping the attacker into an interactive root shell.

The RxRPC Approach: F-Crypt Brute-Forcing and /etc/passwd

The RxRPC variant requires a vastly different exploitation strategy. RxRPC relies on the rxkad security model, which utilizes a specific block cipher known as F-Crypt (Andrew File System Cryptography). Due to the mathematical constraints and implementation of F-Crypt within the RxRPC fast path, deterministically calculating the exact key and ciphertext required to generate a complex 192-byte assembly stub is computationally unfeasible for a local attacker.

Unable to write complex executable code, the attacker pivots their strategy to target a system configuration file instead of a binary executable. The target is the /etc/passwd file.

In Linux systems, /etc/passwd contains user account configurations. Historically, it also contained hashed passwords, but these were moved to the restricted /etc/shadow file for security purposes. In a modern /etc/passwd file, a lowercase ‘x’ is placed in the password field to indicate that the system should look at the shadow file for the actual password. A typical entry for the root administrator looks like this:

root:x:0:0:root:/root:/bin/bash

If the ‘x’ character is removed or replaced with an empty space, the Linux authentication subsystem interprets the absence of the ‘x’ as an instruction that the account requires absolutely no password to log in.

To achieve this, the exploit uses a rapid cryptographic brute-force technique. Because the attacker only needs to alter a single specific byte of memory (changing the ‘x’ to a null byte or space), they do not need to calculate a complex 192-byte payload.

The exploit software rapidly iterates through randomly generated cryptographic keys. For each key, it sets the session via add_key(), sends a generic ciphertext, and triggers the in-place decryption. It then inspects the resulting plaintext in the page cache. It repeats this process continuously until the decryption mathematically collides in a way that overwrites the specific ‘x’ character in the /etc/passwd memory page. Because only a single byte collision is required, this brute-force operation completes in fractions of a second.

Once the ‘x’ is overwritten in the RAM cache, the attacker simply issues the standard command to switch to the root user (su root). The system consults the corrupted page cache, sees an empty password field, asks for no credentials, and grants immediate root access.

The Artificial Intelligence Paradigm Shift in Vulnerability Research

The rapid discovery of both the Copy Fail and Dirty Frag vulnerabilities signifies a profound paradigm shift in the cybersecurity industry, driven by the integration of Artificial Intelligence (AI) Large Language Models (LLMs) into vulnerability research.

The underlying code flaws that enabled the ESP variant of Dirty Frag and the Copy Fail vulnerability had existed in the Linux kernel since 2017. The RxRPC fast path flaw was introduced in June 2023. For years, these vulnerabilities lay dormant, entirely undetected by thousands of human code reviewers and vast automated infrastructure dedicated to securing the kernel.

Historically, security researchers have relied heavily on “fuzzing” to find kernel bugs. Fuzzing involves bombarding a software application with millions of malformed inputs in an attempt to trigger a crash or a memory violation. While fuzzers excel at finding standard buffer overflows, they are inherently limited when dealing with deterministic logic flaws. If a fuzzer triggers the in-place decryption bug and successfully overwrites a page cache entry, the kernel does not crash or panic. Because there is no immediate system failure, the fuzzer registers the interaction as normal behavior and misses the vulnerability entirely.

AI models approach code analysis semantically, rather than through sheer brute-force input. Models tuned for security research can comprehend the complex, multi-layered interactions between entirely distinct kernel subsystems. They can trace how a file manipulated by the Virtual File System (VFS) layer via splice() interacts with memory fragments in the networking layer, and how those specific fragments are improperly handled by a fast-path optimization in the cryptographic layer.

The Theori research team stated that their initial discovery of the Copy Fail vulnerability was an AI-assisted process that took approximately one single hour of scanning the Linux cryptographic subsystem, requiring no complex agents or harnesses. According to David Brumley, a prominent cybersecurity executive, this indicates that “the cost of finding deep logic flaws may have dropped by something like an order of magnitude”.

This capability is further corroborated by experiments conducted by organizations like Mozilla, which tested Anthropic’s Claude 4.6 model against complex software bases. The AI successfully analyzed source code, identified logical vulnerabilities, and autonomously synthesized functional exploit code to prove the impact of the flaws.

The discovery of Dirty Frag by Hyunwoo Kim, occurring mere days after the public release of Copy Fail, strongly implies that researchers are directing AI tooling to hunt for similar MSG_SPLICE_PAGES and in-place cryptographic flaws across the millions of lines of Linux source code. As AI analytical capabilities continue to scale, the industry must anticipate the rapid unearthing of long-dormant logic vulnerabilities that traditional tools have historically overlooked.

The Breakdown of Coordinated Disclosure

The introduction of Dirty Frag into the public domain highlights the inherent fragility of the Coordinated Vulnerability Disclosure (CVD) process within open-source ecosystems.

When a critical vulnerability is discovered, standard security practices dictate an “embargo” period. The discovering researcher privately reports the flaw to the maintainers of the software—in this case, the linux-distros mailing list, which coordinates security responses across all major Linux vendors. The vendors use this embargo period to engineer, test, and package software patches in secret. Once all vendors are ready, the vulnerability details and the protective patches are released to the public simultaneously, minimizing the window of opportunity for malicious actors.

Hyunwoo Kim followed this protocol, privately reporting Dirty Frag and providing functional exploit code to the Linux maintainers on April 30, 2026.

However, open-source development is fundamentally transparent. When a security flaw is identified in the Linux kernel, the upstream kernel maintainers must eventually commit a code fix to the public Git repositories so that the software can be repaired. To maintain the embargo, maintainers often write vague commit messages, attempting to obscure the security implications of the code change.

Despite these efforts, skilled security researchers constantly monitor the Linux kernel commit logs looking for silent security fixes. On May 7, 2026, kernel maintainer Steffen Klassert merged a specific code commit into the public networking tree (netdev/net.git) that corrected the no-COW fast path logic.

The security community reacted instantly. Independent researcher Brad Spengler publicly noted that Klassert’s commit appeared to patch a vulnerability structurally identical to the recently publicized Copy Fail bug. Following this public observation, another independent security researcher operating under the pseudonym “SiCk” analyzed the public commit, recognized the severe implications of the ESP-in-UDP primitive, and independently reverse-engineered a working proof-of-concept exploit.

SiCk published this exploit to GitHub under the title “Copy Fail 2: Electric Boogaloo”. Because a fully functional exploit, derived entirely from public code changes (an “n-day” weaponization), was now freely available on the internet, the embargo was effectively shattered.

Recognizing that malicious actors now possessed the tools to compromise unpatched systems, the linux-distros maintainers abandoned the embargo. They requested that Hyunwoo Kim immediately publish his exhaustive technical documentation and the universal Dirty Frag exploit code to alert the public to the active threat. Consequently, Dirty Frag transitioned from a coordinated disclosure into a global zero-day mitigation crisis, exposing millions of systems before vendors could distribute official patches.

Remediation: Mitigations and Runtime Detection

The immediate public release of exploit code necessitated rapid defensive action from system administrators globally. The vulnerability is particularly dangerous in cloud computing and containerized environments. Because containers (such as those orchestrated by Docker or Kubernetes) share the underlying host operating system’s kernel, an attacker who gains low-privileged access to a single container can execute Dirty Frag to corrupt the host’s page cache, instantly breaking out of the container isolation and taking root control of the entire underlying server node.

Interim Module Blocklisting

Until finalized kernel patches are installed and systems are rebooted, the primary mitigation strategy is to forcibly prevent the Linux kernel from loading the networking modules that contain the flawed fast paths.

Administrators are advised to implement a module blocklist. This is achieved by creating a configuration file for the modprobe utility that maps the loading commands for esp4, esp6, and rxrpc directly to the /bin/false binary, causing the load process to fail instantly.

The widely recommended command sequence to apply this mitigation is:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

To ensure the mitigation survives system restarts and early boot phases, administrators on Debian and Ubuntu-based systems must also regenerate their initial RAM filesystem images:

sudo update-initramfs -u -k all

Operational Consequences: Deploying this blocklist eliminates the vulnerability, but it also intentionally breaks legitimate system functionality. Organizations relying on IPsec for Virtual Private Network (VPN) tunnels will experience immediate network failures when the esp4 and esp6 modules are disabled. Similarly, deployments utilizing the Andrew File System will lose connectivity when rxrpc is unloaded. Administrators must strategically weigh the critical risk of local privilege escalation against the operational disruption of these specific services.

Furthermore, blocklisting the modules does not reverse a successful attack. Because Dirty Frag corrupts the file directly in the physical RAM without touching the hard drive, a modified setuid binary or /etc/passwd file remains active in memory until the cache is cleared. If an administrator suspects an environment has been targeted, they must forcefully flush the Linux page cache, forcing the kernel to reload the pristine, uncorrupted files from the physical storage disk. This is accomplished by writing to the virtual memory subsystem:

echo 3 > /proc/sys/vm/drop_caches

Behavioral Runtime Detection

Organizations hesitant to disrupt their network infrastructure by unloading kernel modules can rely on behavioral runtime detection tools to identify exploitation attempts.

Because the Dirty Frag exploit chain relies on a highly specific sequence of system calls—manipulating network sockets, registering cryptographic keys, and executing zero-copy memory transfers—security tools operating at the kernel level can detect these anomalies. Open-source behavioral engines like Falco, or commercial equivalents like Sysdig, monitor the kernel’s tracepoints.

If a detection engine observes an unprivileged user process attempting to configure XFRM security policies or registering rxkad keys via the kernel keyring, and immediately following those actions with splice() calls that route data into the newly configured sockets, it provides a high-fidelity alert that a Dirty Frag attack is underway. Cloudflare reported successfully relying on similar behavioral profiling to monitor their global infrastructure against the preceding Copy Fail vulnerability, validating the effectiveness of this detection strategy.

Dirty Frag represents a watershed moment in Linux kernel security. The collision of high-performance zero-copy optimizations, legacy cryptographic code paths, and the advent of AI-assisted vulnerability research has exposed a systemic architectural fragility in memory isolation boundaries. As the cybersecurity community continues to adapt to AI-driven threat discovery, organizations must prioritize rapid mitigation strategies and deeply integrated runtime behavioral monitoring to defend against the next generation of complex logic flaws.

Sources

Sysdig — Dirty Frag (CVE-2026-43284, CVE-2026-43500): detecting unpatched local privilege escalation via ESP and RxRPC
The Hacker News — Linux kernel Dirty Frag local privilege escalation
OpenWall oss-security — mailing list thread (7 May 2026)
SC World — Dirty Frag: Linux zero-day and privilege escalation exposure
Ubuntu — Dirty Frag vulnerability: fixes available
xint.io — Copy Fail and Linux distributions

This article was drafted with Markdown Blog.