How Copy Fail Turned Linux's Memory Efficiency Against Itself

Copy Fail Linux vulnerability https://www.pexels.com/photo/close-up-of-rgb-backlit-gaming-keyboard-37099672/

A newly discovered vulnerability, dubbed Copy Fail and tracked as CVE-2026-31431, defies the profile of a classic kernel exploit by requiring no race condition, no version-specific offsets, and no compiled payloads. The same 732-byte Python script achieves root on Ubuntu, RHEL, Amazon Linux, and SUSE without modification, making it a versatile and dynamic exploit. The central tension of this vulnerability is a logic flaw at the intersection of three unrelated subsystem changes that has survived undetected for almost a decade.

How the Pieces Were Laid

The Copy Fail vulnerability required multiple pieces to fall into place over a considerable length of time, beginning over 15 years ago. It took all of these changes throughout this timespan to eventually converge to enable the flaw. First, in 2011, the authencesn cryptographic template was added for Internet Protocol Security (IPsec) Extended Sequence Number (ESN) support, using the destination buffer as scratch space. Under the original interface, this change was largely unremarkable, not enabling vulnerabilities in itself.

Four years later, in 2015, the socket-based interface AF_ALG gained Authenticated Encryption with Associated Data (AEAD) support with a splice path that can deliver page-cache pages into the crypto scatterlist, kept safe by out-of-place operation. Then, in 2017, the in-place optimization chained tag pages by reference into the writable destination scatterlist, finally completing the conditions for exploitation.

The Write That Shouldn't Reach the Cache

This vulnerability is enabled by abuse of the way that the AF_ALG socket interface interacts with splice(). The splice() system call passes file-backed page-cache pages by reference into the crypto subsystem, without any copy or duplication. This lets the attacker push the overwrite directly to the kernel’s file page cache.

Authencesn’s scratch write at dst[assoclen + cryptlen] crosses from the output buffer into chained page-cache pages. This chain is marked by complete attacker control: the target file, write offset, and write value are all fully determined by the caller. The Hash-based Message Authentication Code (HMAC) failure on recvmsg(), which indicates a failed integrity check, does not undo the write, further underscoring the system’s inability to block the attack.

Copy Fail impacts all kernels built since 2017, which includes almost all mainstream Linux distributions. It merely requires one unprivileged local user account to edit in-memory copies of setuid-root binaries that are readable to the user, enabling the attacker to escalate privileges and gain root shell access. This is particularly concerning for multi-tenant environments, shared kernel containers, and CI runners executing untrusted code, though all systems should be patched regardless.

The Corruption Nobody Can See

The Copy Fail exploit chain is notable for its departure from traditional kernel exploits. “If you described this bug to a top kernel researcher — give me a universal Linux LPE, works across major distributions, no race window, no per-kernel offsets, clean container-escape primitive — they probably wouldn’t give you a timeline,” says David Brumley, Chief AI and Science Officer at Bugcrowd, a San Francisco, Calif.-based leader in crowdsourced cybersecurity. “They’d tell you this is the kind of thing that, when it exists at all, tends to sell on the broker market for the price of a house.”

The kernel never marks the modified page dirty, so writeback never occurs, and the on-disk file remains intact. File integrity tooling that compares on-disk checksums is blind to the attack by design, further enabling the attack to go undetected. The in-memory version is what execve(), read(), and mmap() consume—the corrupted page is immediately system-wide and crosses container boundaries via the shared page cache.

What a 732-Byte Script Reveals About Linux Security Assumptions

Research by offensive security company Theori, using AI-assisted penetration testing through its Xint platform, was able to find Copy Fail in under an hour with a single operator prompt, which raises questions about how many similar cross-subsystem intersections may remain unexamined. “That is the real signal,” according to Jacob Krell, Senior Director, Secure AI Solutions and Cybersecurity, Suzu Labs. “Vulnerability research is entering a wild west era where discovery cycles are shorter, exploit development friction is lower, and the volume of high-impact findings will outpace most organizations' capacity to remediate.”

The fix for this vulnerability, which consists of reverting to the pre-2017 out-of-place operation, exposes the fact that the core assumption of the 2017 optimization was never validated across the full AEAD implementation surface. The deeper structural implication of Copy Fail is that integrity enforcement built around disk state cannot detect a class of in-memory corruption that Linux's own efficiency model enables.

Author
  • Contributing Writer, Security Buzz
    PJ Bradley is a writer from southeast Michigan with a Bachelor's degree in history from Oakland University. She has a background in school-age care and experience tutoring college history students.