- Dirty Frag chains two kernel flaws to gain root on every major Linux distribution — and existing Copy Fail mitigations don’t stop it.
- The exploit is deterministic, leaves no crash logs, and proof-of-concept code has been public since May 8.
- Three page-cache corruption vulnerabilities in three years suggest a systemic kernel design problem, not isolated bugs.
A newly disclosed Linux kernel vulnerability dubbed Dirty Frag gives unprivileged users root access on virtually every major distribution — and the mitigations administrators deployed for last week’s Copy Fail flaw won’t stop it.
The exploit chains two separate vulnerabilities — CVE-2026-43284 and CVE-2026-43500 — to corrupt the Linux page cache and overwrite protected files in memory. Researcher Hyunwoo Kim discovered and responsibly disclosed both flaws, but someone broke the embargo before patches were ready, effectively turning Dirty Frag into a zero-day. Kim then published the proof-of-concept exploit code on May 8.
Microsoft’s Defender team has already spotted limited in-the-wild exploitation. In a security blog post, the company said attackers are using Dirty Frag after gaining initial access through compromised SSH accounts, web shells, container escapes, or low-privileged service accounts.
Why Your Copy Fail Mitigations Don’t Work
This is the part that should worry administrators who already applied Copy Fail workarounds. Copy Fail (CVE-2026-31431), which Frontierbeat covered last week, exploited a logic bug in the kernel’s algif_aead cryptographic module. The standard mitigation was to blacklist that module. Dirty Frag bypasses it entirely.
According to Tenable’s research team, the xfrm-ESP vulnerability in Dirty Frag shares the same “sink” as Copy Fail — the page-cache write primitive — but can be triggered on systems that have already applied the algif_aead blacklist. In practical terms: if you mitigated Copy Fail and thought you were safe, you’re not.
Dirty Frag targets two different kernel networking paths instead. CVE-2026-43284 attacks the IPsec ESP receive path (the esp_input() process on esp4 and esp6), while CVE-2026-43500 targets the RxRPC protocol’s rxkad_verify_packet_1() function. Neither exploit alone is reliable across all distributions — some use AppArmor to block namespace creation, others don’t load the rxrpc module by default. But chained together, the pair achieves root on every major distribution Kim tested.
How Page-Cache Corruption Actually Works
Understanding why these exploits keep appearing requires understanding what the page cache does. The Linux page cache stores file contents in RAM so that repeated reads don’t require disk access. When a process reads /etc/passwd, the kernel loads the file into a page-cache page. Every subsequent read of that file serves the cached version — which is fast, but also means that corrupting the cached page corrupts what every process sees when reading that file.
The vulnerability family exploits a specific interaction between the page cache and the kernel’s cryptographic subsystems. When the kernel performs certain in-place cryptographic operations — decrypting an IPsec packet, for instance — it operates directly on the memory buffer that holds the data. If that buffer happens to be backed by a page-cache page (because the attacker used splice() to place a reference to a read-only file into a network buffer), the decryption overwrites the file’s cached contents in RAM.
Here is the simplified attack flow: First, the attacker uses splice() to plant a reference to a page-cache page — say, the page backing /usr/bin/su, a setuid binary — into the frag slot of a network socket buffer. Then the attacker triggers an in-place cryptographic operation on that buffer. The kernel decrypts data in place on the planted frag, which modifies the actual page-cache page in RAM. Every subsequent read of /usr/bin/su now sees the corrupted version, even though the attacker only had read access to the file.
The 4-byte store primitive from CVE-2026-43284 lets an attacker control which 4 bytes get written at a specific offset. The RxRPC vulnerability (CVE-2026-43500) provides the ability to create network namespaces, which is needed to set up the exploit environment on distributions where AppArmor would normally block it. Chaining the two gives a reliable, deterministic path to root.
This is fundamentally the same attack pattern that powered Dirty Pipe in 2022 and Copy Fail last month. The kernel has multiple code paths that perform in-place crypto on buffers without verifying that those buffers are not backed by page-cache pages. Each new vulnerability finds a new code path with the same assumption.
The Page-Cache Problem Keeps Coming Back
CSO Online reported Ben Ronallo, principal cybersecurity engineer at Black Duck, explaining the pattern: Copy Fail, Dirty Pipe, and Dirty Frag all exploit the same root cause — the kernel performs in-place crypto operations on page-cache-backed buffers, creating write primitives for attackers.
The difference is scope. Copy Fail was limited to algif_aead. Dirty Pipe was limited to pipe_buffer. Dirty Frag targets the frag member of the kernel’s struct sk_buff, which means it reaches into networking and memory-fragment handling components rather than a single subsystem. That broader attack surface is why per-module blacklists keep failing: the attack surface spans multiple kernel subsystems.
The timeline is sobering. Dirty Pipe emerged in 2022. Copy Fail was disclosed on April 29, 2026. Dirty Frag followed on May 7 — nine days later. Each vulnerability is distinct, but they share a design pattern: the kernel assumes that page-cache pages passed to cryptographic operations won’t be modified in place. That assumption is wrong, and each new exploit proves it again through a different code path.
As Ars Technica noted, the exploit is deterministic — it works the same way every time, without relying on race conditions or timing windows. It causes no kernel panics, making it stealthy in production environments. The CVSS score for CVE-2026-43284 is 7.8 (High), though CVE-2026-43500 had not yet received a score at time of publication.
Who Is at Risk and What to Do
The highest-risk environments are shared systems where untrusted users or workloads can execute code: multi-tenant servers, CI/CD runners, container hosts, and Kubernetes nodes. SecurityWeek reported that while Dirty Frag is a local privilege escalation flaw — not remotely exploitable on its own — it becomes dangerous when paired with any initial access vector, from phishing to exposed SSH credentials.
Researchers at Google-owned Wiz told Ars Technica that hardened containerized environments running Kubernetes with default security settings are less likely to be broken out of. But virtual machines and less restricted deployments remain significantly at risk.
Debian, AlmaLinux, and Fedora have released patched kernels. Ubuntu has issued mitigation guidance, though several kernel packages still require evaluation. Red Hat confirmed that RHEL 8, 9, and 10 plus OpenShift 4 are affected, with fixes being expedited. LinuxIAC reports that openSUSE and SUSE are also tracking the issue.
The recommended response is straightforward: apply a patched kernel and reboot. Anyone who cannot patch immediately should follow vendor-specific mitigation steps, which typically involve disabling the affected kernel modules — though as the Copy Fail experience showed, module-level mitigations are a stopgap, not a solution.
Three page-cache corruption vulnerabilities in three years suggest the Linux kernel has a design-level weakness in how it handles cryptographic operations on shared memory pages. Patching individual code paths works — until the next researcher finds another one. The kernel development community may eventually need to address the root cause: ensuring that in-place crypto operations can never write back to page-cache-backed pages, regardless of which subsystem invokes them. Until then, the Dirty Pipe family is likely to keep growing.
FAQ
What is Dirty Frag?
Dirty Frag is a Linux kernel local privilege escalation vulnerability that chains two flaws (CVE-2026-43284 and CVE-2026-43500) to allow unprivileged users to gain root access by corrupting the kernel’s page cache through networking and memory-fragment handling components.
How is Dirty Frag different from Copy Fail?
Copy Fail (CVE-2026-31431) targeted the algif_aead crypto module. Dirty Frag targets the IPsec ESP and RxRPC networking paths. While both corrupt the page cache through in-place crypto operations, Dirty Frag bypasses the algif_aead blacklist that was the standard Copy Fail mitigation.
Is Dirty Frag remotely exploitable?
No. Dirty Frag requires local access to the target system. But attackers commonly pair it with an initial access vector — compromised SSH credentials, web shells, or container escapes — to escalate from a low-privilege foothold to root.
Which Linux distributions are affected?
Virtually all major distributions with kernels released since 2017 are affected, including Ubuntu, RHEL, Debian, Fedora, AlmaLinux, CentOS Stream, openSUSE, and Amazon Linux. Patches have been released for some distributions; others are pending.
What should I do right now?
Apply the patched kernel from your distribution vendor and reboot. If you cannot patch immediately, disable the affected kernel modules (esp4, esp6, rxrpc) as a temporary mitigation, following your vendor’s specific guidance.
