All articles

DirtyFrag and Copy Fail2 Show the Page-Cache Bug Class Is Not Done

DirtyFrag and Copy Fail2 are not new AI-attributed findings, but they are important CopyFail-adjacent evidence: Linux still has dangerous seams where zero-copy networking, page-cache provenance, and in-place crypto meet.

DirtyFrag and Copy Fail2 belong on Bugflation, but not in the findings ledger.

The distinction matters. CopyFail is a ledger entry because the public record names Xint Code in the discovery workflow. DirtyFrag and Copy Fail2, as currently published, do not. They are human researcher and proof-of-concept work that followed the CopyFail disclosure and explored the same broader failure class.

That makes them article material, not ledger material. They are still important because they show what happens after an AI-assisted kernel finding lands in public: the research community immediately starts variant analysis, exploit engineering, backport checking, and module-by-module pressure testing. In that sense, they are part of the bugflation story even without AI attribution.

Last checked: May 8, 2026.

The Short Version

CopyFail, DirtyFrag, and Copy Fail2 all point at the same uncomfortable Linux security theme: page-cache-backed data can travel through high-performance zero-copy paths into kernel objects that later mutate their buffers in place. If the kernel forgets that a page came from a read-only file mapping, an unprivileged user can sometimes turn a read primitive into a page-cache write.

The details differ:

The operational lesson is not that one module was unlucky. The lesson is that Linux has accumulated many optimized data paths where ownership of memory is implicit, local, and easy to lose during composition.

What Copy Fail2 Adds

Copy Fail2: Electric Boogaloo is not a second Xint finding and does not appear to describe a new root cause separate from the DirtyFrag xfrm-ESP issue. It is better understood as a compact exploit and regression artifact for the ESP-in-UDP MSG_SPLICE_PAGES no-COW path.

The README describes it as an unprivileged Linux local privilege escalation via the xfrm ESP-in-UDP zero-copy path. Its target is blunt: mutate the page-cache copy of a readable file so later consumers see attacker-selected bytes. The published exploit package chooses /etc/passwd as the policy surface, rewriting an existing non-login service account line into a valid UID 0 account with an empty password field, then using normal authentication behavior to enter that account.

The interesting part is the primitive, not the payload. Copy Fail2 shows that the xfrm/ESP path can be turned into repeated byte-level page-cache mutation. It does so by selecting crypto state that causes the in-place ESP operation to produce a desired byte at a target offset. That is a different exploit style from the CopyFail and DirtyFrag authencesn 4-byte write narratives, but it presses on the same ownership bug: an skb frag backed by a file page should not be treated as a private mutable packet buffer.

The repository also includes an IPv6 variant. Its README says the same issue exists in esp6_input and frames the v6 code as a dual path. The upstream patch text I checked on netdev and stable mailing-list mirrors covers both IPv4 and IPv6: it marks shared datagram frags in both ip_output.c and ip6_output.c, and it makes both esp_input and esp6_input fall back to copy-on-write when skb_has_shared_frag() is present. That does not make the IPv6 PoC irrelevant. It makes it a useful warning about downstream backports: defenders need to verify the exact vendor kernel they run, not assume that a headline fix covers every protocol twin.

The other notable feature is the user-namespace harness. Copy Fail2 ships a helper that tries to find a usable user namespace plus network namespace path on systems with Ubuntu-style AppArmor restrictions. That is exactly the kind of adaptation defenders should expect. A distro hardening choice may close the simple route, but exploit authors will test the policy boundary, fallback paths, and installed profiles.

What DirtyFrag Adds

DirtyFrag, announced on oss-sec by Hyunwoo Kim on May 8, 2026, is broader than Copy Fail2. It names a vulnerability class and chains two separate bugs:

• xfrm-ESP Page-Cache Write.
• RxRPC Page-Cache Write.

The xfrm-ESP half overlaps with the netdev patch trail that Copy Fail2 points at. The root problem is a no-COW fast path. MSG_SPLICE_PAGES can put pages from a pipe directly into an skb. TCP already marks those shared frags so later mutating paths can make a private copy first. The IPv4 and IPv6 datagram append paths did not do the equivalent marking for UDP skbs. An ESP-in-UDP packet assembled from those pages could then arrive at ESP input looking like an ordinary uncloned nonlinear skb. ESP input could decrypt in place over data it did not privately own.

The RxRPC half is different and, in some ways, more worrying. DirtyFrag’s write-up says the RXKAD verification path performs in-place single-block decryption over skb data. If that skb data is a frag backed by a page-cache page, the verification path becomes a write sink. Unlike the ESP variant, the RxRPC path described by DirtyFrag does not require creating a user namespace; its limiting factor is module availability. The write-up says rxrpc.ko is not present in every major distribution build, but is available on Ubuntu in the configuration they tested.

DirtyFrag also documents the disclosure problem. The oss-sec announcement says the embargo was broken, no CVEs existed for the DirtyFrag vulnerabilities at publication time, and distribution patches were not yet available. At the same time, the ESP side already had an upstream netdev patch trail by May 7. That is the messy middle defenders actually live in: public exploit code, mailing-list patches, no clean CVE inventory yet, and vendor kernels that may lag upstream or backport only parts of the relevant series.

The Shared Bug Class

The common pattern is compact:

1. A user-readable file page enters a zero-copy path.
2. That page is attached to a kernel transport object by reference.
3. A later subsystem assumes the buffer is packet-private or otherwise safe to mutate.
4. In-place crypto or scratch-buffer behavior writes into the page.
5. The page cache now contains bytes the caller could not write through the filesystem permission model.

That is why the comparisons to Dirty Pipe are not marketing noise. Dirty Pipe was also about page-cache mutation through a subtle ownership and flags failure. CopyFail moved the pattern into AF_ALG and the crypto scatterlist world. DirtyFrag moves it into skb frags and network crypto. Copy Fail2 then shows how quickly a public patch trail can be transformed into a portable exploit package that exercises the same class.

The root cause is not “crypto is dangerous” or “splice() is dangerous” in isolation. The root cause is the composition of:

• zero-copy data movement,
• page-cache-backed file data,
• mutable packet or crypto buffers,
• fast paths that skip copy-on-write,
• and subsystem-local assumptions about who owns a page.

Each individual optimization is understandable. Together, they create a review problem that ordinary local reasoning handles poorly.

Why Standard Mitigations Do Not Help Much

These are bad local privilege escalation bugs because they are logic bugs, not memory-corruption races in the usual sense.

There is no need to defeat KASLR with a kernel address leak. There is no traditional heap grooming requirement. There is no race window that makes the attack flaky. The exploit surface is closer to “ask the kernel to process a valid-looking data path, then make it mutate the wrong physical page.”

That is why CopyFail became a CISA Known Exploited Vulnerabilities entry so quickly, and why DirtyFrag’s release is operationally serious even before CVE assignment settles. If a primitive can deterministically alter the in-memory view of /usr/bin/su or /etc/passwd, the rest of the privilege escalation is policy plumbing.

User namespaces remain central, but they are not a complete explanation. The ESP path needs enough privilege to configure xfrm state, so unprivileged user namespaces and network namespaces matter. Ubuntu has invested in AppArmor-based restrictions for unprivileged user namespaces in 24.04 and later, and those restrictions are a real hardening layer. But DirtyFrag’s RxRPC variant is explicitly valuable because it covers a different blind spot, and Copy Fail2’s helper code shows that researchers will test whether userns restrictions are policy-hard or only path-hard.

What This Says About Linux Security Now

Linux security is not failing because maintainers are careless. It is under pressure because old performance decisions are being re-read with better tools, better exploit templates, and faster variant analysis.

The page-cache bug class is especially punishing because it crosses subsystem boundaries. Filesystem permissions say the caller can read a file. Pipes say a page can be moved without copying. Networking says an skb frag can represent packet payload. Crypto says in-place operation is allowed when source and destination are the same. No single sentence sounds absurd. The vulnerability appears when the same physical page keeps its file identity while being treated as mutable transport-owned memory.

This is also a preview of the post-CopyFail research loop. CopyFail was AI-assisted in the public record; DirtyFrag and Copy Fail2 are not. But once CopyFail made the page-cache plus in-place crypto shape visible, sibling paths were obvious targets for human and tool-assisted variant hunting. Bugflation is not only “AI finds more first bugs.” It is also “one public bug creates a larger, faster variant search market.”

For maintainers, that changes what “fixed” should mean. A narrow patch that blocks one named exploit is not enough. The review question after CopyFail should have been: where else can page-cache-backed zero-copy data become a mutable crypto destination? DirtyFrag is the answer arriving in public.

What Defenders Should Do

The immediate work is conventional but urgent: track vendor advisories, update kernels as soon as fixed packages are available, and apply temporary module mitigations only with a clear rollback plan. DirtyFrag’s own announcement suggests disabling the affected ESP and RxRPC modules while waiting for distribution fixes; that is a serious operational tradeoff, not a free toggle.

For teams that build or validate kernels, the better response is broader:

• Test both IPv4 and IPv6 protocol twins when a fix touches one network path.
• Treat MSG_SPLICE_PAGES, skb frags, and page-cache provenance as a shared audit theme.
• Add regression tests that prove externally backed frags are copied before any in-place transform.
• Review old “avoid copy” commits with the same suspicion usually reserved for obvious memory-safety changes.
• Keep user namespace policy tight, but do not treat it as the only boundary.
• Monitor public PoC repositories as regression tests and exploitability signals, not just as offensive artifacts.

For vulnerability researchers, DirtyFrag and Copy Fail2 show where the bar is moving. The valuable work is no longer only finding a single spectacular primitive. It is mapping the class, proving which subsystems share it, showing which mitigations actually close it, and forcing patch review to follow the data flow rather than the brand name.

That is why these cases deserve a place on Bugflation as analysis. They are not AI-attributed findings. They are what happens next: public AI-assisted discovery turns into human variant research, exploit compression, patch verification, and a much shorter defender timeline.

Sources

• DirtyFrag repository
• DirtyFrag technical write-up
• DirtyFrag oss-sec announcement
• Copy Fail2 repository
• Copy Fail2 IPv6 variant
• netdev patch: xfrm ESP shared skb frags
• stable-list mirror of Kuan-Ting Chen’s patch
• CopyFail landing page
• Xint/Theori CopyFail write-up
• NVD: CVE-2026-31431
• CISA KEV catalog entry for CVE-2026-31431
• Ubuntu 24.04 release notes: unprivileged user namespace restrictions

Published May 8, 2026 by Mounir Idrassi. Follow new articles and findings through the RSS feed.