Dirty Frag and Copy Fail: Linux Page Cache Exploits

Security researcher Hyunwoo Kim (@v4bel) published Dirty Frag on May 7, 2026. It is a local privilege escalation flaw in the Linux kernel. The scope is broad — mainstream distributions and multiple China-localized systems are affected.

The attack is dangerous because:

• Any unprivileged user triggers it. No root needed.

• It is deterministic. No race conditions. Failed attempts don’t crash the kernel.

• It writes to Page Cache. In-memory copies of read-only files get corrupted.

• Two independent paths exist. xfrm-ESP and RxRPC.

• Coverage is broad. Ubuntu, RHEL, CentOS Stream, AlmaLinux, openSUSE, Fedora. Copy Fail already confirmed on multiple China-localized systems.

• Fixing Copy Fail doesn’t block Dirty Frag. Different kernel path.

Copy Fail used AF_ALG. Dirty Frag routes through skb->frags and kernel decryption. Same outcome. Different vector. That means patching one doesn’t stop the other.

How It Works

The on-disk file never changes. The in-memory copy gets poisoned.

Normally, read-only files stay read-only. Dirty Frag circumvents this by using splice() to map a read-only file’s page cache into a network packet (skb->frags). The kernel then decrypts data in that region — but it skips the COW (Copy-on-Write) check. Result: the Page Cache gets written to directly.

read-only file → page cache → splice() into skb->frags 
→ kernel decryption (COW skipped) → page cache is corrupted

read-only file → page cache → splice() into skb->frags 
→ kernel decryption (COW skipped) → page cache is corrupted

read-only file → page cache → splice() into skb->frags 
→ kernel decryption (COW skipped) → page cache is corrupted

On-disk content is intact. In-memory copy is poisoned. The next time the kernel or an application reads from that cache, it reads corrupted data. That is the opening for privilege escalation.

Two Attack Paths

Both paths write to Page Cache. Neither requires the other to succeed.

xfrm-ESP (ESP Encapsulating Security Payload)

This path exists in kernels since 2017. The vulnerability is in esp_input(). When the skb is non-linear but has no frag_list, the code skips the COW check and does in-place AEAD decryption. An attacker can place a read-only file page into skb->frags via splice() and achieve a 4-byte write to Page Cache.

Constraint: usually requires a user or network namespace. Systems that block unprivileged namespace creation are harder targets.

RxRPC (Remote Procedure Call over UDP)

This path affects kernels from June 2023 onward. It does not require namespaces. It achieves an 8-byte write, typically targeting /etc/passwd.

Constraint: the rxrpc kernel module must be loaded. On Ubuntu and similar systems, it loads by default.

The coverage logic: block namespaces, the attacker tries RxRPC. Patch AF_ALG, the attacker routes through xfrm-ESP or RxRPC. Two independent paths. One patch doesn’t close both.

Confirmed Across Mainstream and China-Localized Distributions

The Dirty Frag public repository lists tests covering multiple mainstream Linux distributions:

Copy Fail’s impact surface is also worth examining separately. ThreatBook Intelligence Bureau conducted manual verification across multiple operating systems in their analysis “Manually Verified: Linux LPE Vulnerability Confirmed Across Multiple Localized Systems,” covering both mainstream and China-domestic Linux distributions:

Looking at both data sets together, the conclusion is clear: this is not a niche kernel corner case. Dirty Frag targets well-traveled kernel paths — splice(), Page Cache, skb->frags, xfrm-ESP, RxRPC — that are present across essentially every modern Linux distribution. Copy Fail has already been manually confirmed to affect multiple China-domestic Linux ecosystems built on RHEL-lineage, Debian/Ubuntu-lineage, or community long-term kernel branches.

For any organization running non-standard or localized Linux distributions, the risk assessment cannot stop at “is our distro name on the public list?” The relevant question is whether the underlying kernel paths, modules, and patch state match the affected configurations.

Dirty Frag, Copy Fail, Dirty Pipe: The Family Tree

They are in the same family but use different entry points:

• Dirty Pipe — Pipe buffer corruption. Targets pipe buffer state errors.

• Copy Fail — AF_ALG socket corruption. Reaches Page Cache via splice() + crypto interface.

• Dirty Frag — Network packet corruption. Reaches Page Cache via skb->frags + xfrm-ESP or RxRPC.

Dirty Frag is not Copy Fail with a new name. It takes a completely different kernel path. If you fixed Copy Fail by disabling AF_ALG, Dirty Frag still works via skb->frags.

The common lesson: an untouched on-disk file does not mean the in-memory version is clean.

What To Look For

Copy Fail mitigation (CVE-2026-31431) blocks AF_ALG. It does not block skb->frags. Organizations that mitigated Copy Fail still need to assess xfrm-ESP and RxRPC exposure.

What To Do

Treat the two chains separately.CVE-2026-43284 (xfrm-ESP) and CVE-2026-43500 (RxRPC) are separate vulnerabilities with separate fixes. Check:

• Is rxrpc loaded? (lsmod | grep rxrpc)

• Can unprivileged users create namespaces? (sysctl kernel.unprivileged_userns_clone)

For China-localized systems, verify directly with the OS vendor. UOS, Kylin, openEuler, CTyunOS, and others follow their own patch timelines. Upstream patch availability (RHEL, Ubuntu) is not a proxy for their status.

Prioritize container nodes, CI/CD runners, and multi-tenant hosts. These share a kernel across many low-privilege processes. One successful escalation spreads. Until patches ship, enforce stricter namespace limits and review CI/CD privilege models.

Run actual tests. Static scanners say “affected” or “not affected” based on version numbers. They cannot answer: Is this kernel path exploitable on my system? Do my security controls alert? Does my SOC see it?

digiDations ingested both Copy Fail and Dirty Frag into ORION and translated the attack chains into validation rules in ATLAS. Organizations can run the full exploit on authorized test nodes and get concrete answers: exploitable? Alerted? Correlated?

The Window

Copy Fail today, Dirty Frag tomorrow. The next variant in the Page Cache family won’t wait for organizations to finish patching the previous two.

The real problem is not the technical complexity. It is how fast the window closes. From disclosure to PoC in hours. From PoC to production attack in days.

Patching is necessary. But “patch installed” and “defense posture is actually closed” are not the same thing. Only running the attack on authorized test infrastructure — and seeing if security controls catch it — closes that gap.

References

• Copy Fail official page: https://copy.fail/

• NVD: CVE-2026-31431: https://nvd.nist.gov/vuln/detail/CVE-2026-31431

• Microsoft Security Blog: CVE-2026-31431 Copy Fail vulnerability enables Linux root privilege escalation across cloud environments: https://www.microsoft.com/en-us/security/blog/2026/05/01/cve-2026-31431-copy-fail-vulnerability-enables-linux-root-privilege-escalation/

• V4bel/dirtyfrag GitHub repository: https://github.com/V4bel/dirtyfrag

• Dirty Frag technical write-up: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md