Copy Fail and Its Descendants: A Real Human's Guide to Kernel Page-Cache LPEs

Executive Summary

Recent disclosures around two recent Linux LPEs Copy Fail and Dirty Frag discovered with the assistance of AI have exposed a broader class of Linux kernel local privilege escalation vulnerabilities involving page-cache overwrite primitives. This analysis separates the technical reality from the noisy wave of AI-generated disclosures and recycled proofs of concept, emphasizing the need for defenders to understand the actual vulnerability mechanics, exploit constraints, and operational impact rather than relying on misleading headlines or obfuscated public PoCs.

How did we get here?

It was the dark and stormy night of April 29, 2026, when xint.io disclosed a high-severity local privilege escalation vulnerability in the Linux Kernel crypto subsystem that they dubbed ‘Copy Fail’, an exploit that promises “732 Bytes to Root on Every Major Linux Distribution." In the month since this original disclosure, we have seen multiple similarly themed Linux LPE disclosures following similar exploit paths. Many of these exploits were found with AI assistance; in some cases, entire disclosures seem to have been authored by LLMs.

But while AI-generated vulnerability advisories are often a pain to interpret accurately and efficiently amid all the hype, that (unfortunately) doesn’t mean the vulnerabilities they describe aren’t real. The recent spate of Linux kernel LPEs — of which there are now at least five — demonstrates what is already becoming a common pattern: An AI-assisted vuln discovery generates high levels of chatter online and is then followed by a stream of very similar discoveries as researchers train their own AI models on the original find. We’ve seen at least one public proof-of-concept exploit (ostensibly targeting CVE-2026-46300) that turned out to be a new zero-day bug, and Copy Fail itself (CVE-2026-31431) has already been firmly established as the most publicly researched vulnerability of 2026, with 140+ valid (if derivative) exploits.

For a nuanced vulnerability class such as kernel page-cache write primitives, many of the explanations around how and why these vulnerabilities (and their corollary exploits) exist have either fallen short or have been entirely misconstrued by LLMs. This blog aims to cut through this noise and concisely explain the internals, externals, flaws, and shortcomings of both the vulnerabilities themselves and their exploits, focusing on:

• CVE-2026-31431: “Copy Fail”, a vulnerability in a cryptography subsystem.
• “Dirty Frag” (CVE-2026-43284, CVE-2026-43500): Two separate vulnerabilities inside the network subsystem.
• CVE-2026-46300: "Fragnesia,” a third vulnerability in the network subsystem, similar to “Dirty Frag”
• CVE-2026-43494: “PinTheft,” another vulnerability in the network subsystem, inside RDS (Reliable Datagram Sockets). Limited exposure compared to the other vulnerabilities.

Copy Fail: Root Cause

There are a few primitives that we need to understand in order to grasp this vulnerability.

The first is the kernel page cache. Like any good cache, the Linux kernel page cache stores frequently used file data in RAM, allowing for much faster retrieval and operation of these files, as opposed to having to make the comparatively "long" trip of reading them from disk. These pages are stored in RAM and are what the kernel actually "uses" when performing operations on a file. If a file is edited normally, the kernel updates the cache and marks them as "dirty", meaning they need to be written to disk to ensure parity between the cache and disk. The overwriting-ness of this family of vulnerabilities means the cache never gets marked as dirty, and the kernel blindly reads the version of the file living in the page cache.

We also need to understand the splice() system call. As described in the man page, splice() lets Linux move data between file descriptors inside the kernel, typically using a pipe as the bridge, without copying the data through userspace. Like the kernel page cache, it is not inherently "vulnerable", but rather a legitimate I/O optimization that is abused.

The Copy Fail vulnerability resides in the algif_aead portion of the Linux Kernel crypto subsystem. Depending on your system, this is either built into the kernel image at compile time, or dynamically loaded via algif_aead.ko. For the uninitiated, that's a lot of letters that don't make sense. Breaking it down:

• algif = Algorithm Interface
• aead = Authenticated Encryption with Associated Data

Basically, the kernel needs to do cryptography operations on data (disk encryption, integrity checks, etc), but can't rely on libraries like OpenSSL, so it is either shipped with, or can dynamically load, parts of a "crypto subsystem." Some of this functionality can be exposed to userspace via AF_ALG, allowing userspace processes to send data that is ultimately processed by kernel crypto code.

We won’t do a deep dive into the vulnerable code itself. For our purposes, the important detail is that a specific algif_aead path can produce a controlled four-byte write outside its intended output region. By using splice() to pass page-cache-backed file data into this path, an attacker can redirect that write into the kernel’s cached copy of a readable file, four bytes at a time. In layperson's terms, we can use this to overwrite how the kernel "sees" any file that we can normally read.

Copy Fail: Disclosure interpretation challenges

The original disclosure and exploit, as well as most of the 300+ public exploits that followed, were primarily authored with AI. While LLMs have proved to be valuable research tools, they still make false statements, ranging from slightly misleading to blatantly wrong. This section will first explain how the exploit actually uses the previously described overwrite, and then point out some of the blunders that the machines made in the process.

For the original Copy Fail disclosure, the vulnerability finders used their four-byte overwrite (that rhymes!) to overwrite the page cached su binary. The researchers chose the specific target because of its presence on an overwhelming majority of Linux systems; su is also often set with the setuid bit, meaning any user can run it, and it will perform operations that are normally gated off to the root user. While this is a nice exploit primitive, it is temporarily destructive, opening a gaping hole that attackers hiding on the box will be able to use as their own backdoor, or in many cases, that crashes production software.

The more glaring issue is the actual exploit code itself and the focus on flashy claims that made interpretation more difficult for defenders (a common scenario for AI-assisted discoveries that’s not unique to this case). For the Copy Fail disclosure, a lightly obfuscated PoC that contained a compressed payload and minimized code was provided, which attempted to make the exploit as "short" (or “small”) as possible. None of this was needed, and all of it made the exploit harder for a defender to understand:

• The exploit imports multiple libraries as a single letter — e.g., the first line of the exploit is "import os as g,zlib,socket as s"
• It uses inlined single-letter function definitions
• The final payload is a zlib-compressed ELF file, despite the finders’ explicit claim that the exploit uses " no compiled payloads", embedded as a hex string inside the Python file.

These sorts of low-level kernel exploits are generally not easily understandable at first glance, but one of the major steps AI-assisted vulnerability disclosures can take to help defenders interpret impact and risk correctly is to ensure that exploit code is well-documented and explained, as tempting as it may be to artificially minimize or obfuscate PoCs for the sake of a headline.

Predictably, hundreds of aspiring researchers took the original (already difficult-to-interpret) disclosure, fed it into their favorite AI tools, and published a storm of 300+ GitHub repositories claiming to have unique and novel implementations of the original vulnerability. In reality, less than 15% of the exploits VulnCheck researchers reviewed contained substantive improvements; examples of value-adds include things like backporting the original exploit for older versions of Python, creating cross-platform actual dependency-less versions, or porting the exploit to various languages. Over 85% of the exploits we reviewed were copy-pastes or “AI-enhanced” versions that offered colorized terminal output. This makes it incredibly difficult for defenders to decipher and extract real insights from the already confusing world of kernel exploits.

Dirty Frag: Root Cause

Within a week of Copy Fail, a similar vulnerability nicknamed “Dirty Frag" was published courtesy of V4bel's GitHub disclosure. A full explanation of the timeline is in the next section. Dirty Frag essentially uses the same primitives we explained previously with Copy Fail, but this time in the networking subsystem via IPsec's xfrm-ESP path in esp4.ko and the AF_RXRPC path inrxrpc.ko. It’s important to note that while they were originally disclosed as a single exploit, they have been assigned two separate CVE IDs, CVE-2026-43284 and CVE-2026-43500. Once again, lots of scary acronyms:

• IPsec = Internet Protocol Security
• ESP = Encapsulating Security Payload
• XFRM = Transform

IPsec is a suite of Layer 3 protocols that is used to authenticate and encrypt packets over the internet, and ESP is the primary protocol in this suite. Before the OpenVPN and WireGuard days, this was the protocol that powered the majority of VPNs, and it still sees some use today, mostly in enterprise. In the kernel, xfrm is the subsystem that actually implements and handles the packet transformation for the different protocols implemented inside the kernel. The ESP-xfrm (the ESP component of the XFRM framework) is the bit that is actually performing the encryption and decryption of the received IPsec traffic.

Once again, inside this path of code, ESP-xfrm can modify packet data in-place (for optimal I/O) even if that packet data is secretly a shared page-cache page. This gives us yet another 4-byte overwrite that we can chain into a privilege escalation.

Similarly, for AF_RXRPC:

• AF = Address Family
• RxRPC= Rx Remote Procedure Call

RxRPC is another protocol implemented in the network subsystem of the Linux kernel, primarily to provide a reliable transport stream over UDP (I know...) and is commonly used for AFS (The Andrew Filesystem), a distributed / networked filesystem. Linux exposes it through the AF_RXRPC socket family, with the kernel RxRPC code handling connection setup, packet parsing, and the like. If you've been tracking, you can probably guess what the underlying vulnerability is. (Hint: There's a reason it's included in this blog!)

If you guessed that RxRPC ultimately does more insecure in-place modifications of data that gives us the shared page-cache page overwrite, (this time 8 bytes) you'd be correct! However, in this case, it’s a little more difficult. For our primitive, RxRPC writes decrypted bytes to the destination buffer, adding an additional layer of complication, and requires a bit of brute-forcing that can get computationally expensive for larger payloads. Essentially, whatever data exists at that file offset gets decrypted via FCBC with the attacker's 56-bit key, so we brute-force the key in userspace until the decryption output matches our desired payload.

Dirty Frag: Disclosure interpretation challenges

The Dirty Frag disclosure was much more confusing, largely because of a muddled timeline. As soon as Copy Fail dropped, other researchers naturally began searching for similar vulnerabilities in parts of the Linux kernel, and where there's smoke there's fire. A Dirty Frag disclosure timeline is as follows. (Sourced from OpenWall and kernel.org commits.

• April 29 - 30, 2026: Hyunwoo Kim (V4bel) privately discloses both CVEs to Linux kernel maintainers, alongside public patches to the netdev mailing list, targeting a May 12, 2026 coordinated disclosure date.
• April 30, 2026: Kuan-Ting Chen also discloses the vulnerability.
• May 4, 2026: Kuan-Ting Chen posts patches to the mailing list.
• May 7, 2026:Patches are merged into netdev tree.
• May 7, 2026: 0xdeadbeefnetwork publishes "Copy Fail 2: Electric Boogaloo," breaking embargo. This is the first public disclosure of the CVEs; 0xdeadbeefnetwork used the ESP-xfrm (IPv4/IPv6 UDP stack) vuln (CVE-2026-43284) with a separate AppArmor privileged user namespace bypass.
• May 7, 2026: Hyunwoo Kim makes their disclosure public following the broken embargo, revealing the second RxRPC bug alongside the original ESP-xfrm vulnerability.
• May 12, 2026: Originally planned coordinated disclosure date.

Fragnesia and PinTheft: The honorable mentions

With the DirtyFrag patch pushed downstream into kernels, everyone slept peacefully for a few nights, free of copy-on-write vulnerabilities. Unfortunately, those nights didn’t last long, when William Bowling (Zellic) of the v12 security team (also an agentic/LLM-assisted vulnerability research organization) published a new vulnerability. On May 13th, he disclosed the fact that the original DirtyFrag patch had introduced a new codepath into skb_try_coalesce(), which made a long-lived vulnerability in the function actually exploitable. Later on May 15th, there was also a separate patch bypass variant inside skb_segment() that was also disclosed and shortly patched by the netdev security team.

Very shortly after, Aaron Easu of v12 disclosed PinTheft. The bug lies in the RDS (Reliable Datagram Sockets) networking subsystem, where a specific sequence of memory operations causes the kernel to lose track of who actually owns a page of memory. By repeating that sequence multiple times, an attacker can free a page the kernel still has a pointer to, wait for that pointer to be given to a privileged binary, and write to it through that stale pointer. Their proof-of-concept scans for and overwrites the pagecached version of a SUID-root binary with a small payload, and then executes it for a root shell. It relies on the RDS kernel module, which only ships by default on Arch Linux amongst common distributions, limiting exposure.

Conclusion

These five bugs all follow the same path: kernel I/O paths modifying data in place without checking whether the target is a shared, clean page-cached page. Each one produced a bounded overwrite that the kernel didn’t mark as dirty.

The question moving forward isn’t whether AI-assisted vulnerability research is valid or here to stay. It clearly is, and the five vulnerabilities we discussed exist as evidence. The window between an upstream commit and a working PoC for kernel exploits appearing on GitHub has collapsed from weeks to hours. None of this is going away. The more useful question for defenders is separating signal from noise in a new era where over 85% of published exploits are colorized rewraps of the original and where primary exploit mechanics get buried under compressed payloads built for headlines rather than defender comprehension. Moving forward, the relevant unit of analysis is the underlying primitive and how vulnerabilities are being weaponized in the real world, not the CVE record itself.

About VulnCheck

VulnCheck’s research team tracks real-world exploitation, attacker infrastructure, and exploit patterns across our Canary Intelligence, Exploit & Vulnerability Intelligence (EVI), and IP Intelligence datasets. By delivering machine-consumable, evidence-driven intelligence on new vulnerabilities and how real attackers can use them in the wild, VulnCheck helps organizations prepare earlier, respond decisively, and verify exploitation without relying on inaccurate scores or delayed consensus.

For more analysis of vulnerability and exploit trends, see the 2026 VulnCheck Exploit Intelligence Report, or check out or our blogs 2026 State of Exploitation: Exploiting The Network Edge and The First CVE Wave: Signs That AI-Assisted Vulnerability Discovery Is Reshaping Disclosure Volumes.

Sign up for the VulnCheck community today to get free access to our VulnCheck KEV, enjoy our comprehensive vulnerability data, and request a trial of our Initial Access Intelligence, IP Intelligence, Canary Intelligence, and Exploit & Vulnerability Intelligence products.