Why Copy Fail Is Different From Previous Linux LPEs

To understand why Copy Fail caused immediate alarm across the security community, it helps to compare it to prior high-profile Linux kernel exploits:

Copy Fail is a straight-line logic flaw. It triggers without races, retries, or crash-prone timing windows. The exact same script works across Ubuntu, Amazon Linux, RHEL, and SUSE — no per-distro offsets, no recompilation, no version checks. The entire exploit requires only Python 3.10+ and standard library modules (os, socket, zlib).

Technical Root Cause

The Affected Component: algif_aead and AF_ALG

The Linux kernel’s AF_ALG interface exposes hardware-accelerated cryptographic functions to userspace applications. The vulnerable module within this interface is algif_aead, which handles Authenticated Encryption with Associated Data (AEAD) operations.

How This Bug Was Found

The story behind the discovery is as interesting as the vulnerability itself. A researcher at Theori named Taeyang Lee had been studying the intersection of the Linux crypto subsystem and page-cache-backed data — territory he’d mapped in earlier kernelCTF work. His hypothesis was that AF_ALG combined with splice() creates a path where unprivileged userspace can feed file-backed page cache pages directly into the kernel crypto subsystem, and that this interaction might be an underexplored source of vulnerabilities.

From there, the team used Xint Code, an AI-assisted security research tool, to scale the analysis across the entire crypto/ subsystem. The operator prompt given to the scan was deliberately minimal — essentially just pointing the tool at the crypto subsystem and noting the key observation about splice() delivering page-cache references to crypto TX scatterlists. About an hour later, Copy Fail emerged as the highest-severity finding. The researchers also noted that the scan surfaced additional high-severity vulnerabilities that are still in coordinated disclosure.

Understanding the Pieces That Came Together

The vulnerability doesn’t stem from a single bad commit. It is the collision of three independent kernel changes made in 2011, 2015, and 2017 — none of which was problematic in isolation. Understanding why Copy Fail works requires understanding each piece.

AF_ALG: The Crypto Subsystem’s Userspace Door

AF_ALG is a socket type that exposes the Linux kernel’s cryptographic API to unprivileged userspace. Since roughly 2003, any user can open an AF_ALG socket, bind it to a supported algorithm — symmetric ciphers, hash functions, AEAD constructs — and use it to encrypt or decrypt data. There is no capability requirement. This is intentional: hardware-accelerated cryptography in the kernel can benefit any application, so the interface is wide open.

splice(): Zero-Copy File I/O

splice() is a Linux system call that moves data between file descriptors and pipes without making userspace copies of the data. Instead of copying bytes, it passes references to the underlying kernel memory pages — specifically, the physical pages that sit in the page cache. When a file is memory-mapped or opened for reading, the kernel maintains cached copies of its contents in what’s called the page cache. splice() works by handing off references to those cached pages directly. This is great for performance. It becomes a problem when those page references end up somewhere they aren’t supposed to.

authencesn: The IPsec ESN Wrapper

authencesn is an AEAD (Authenticated Encryption with Associated Data) template added to the Linux kernel in 2011 to support IPsec’s Extended Sequence Number (ESN) mode, defined in RFC 4303. IPsec uses 64-bit sequence numbers to prevent replay attacks, but they’re split in a somewhat awkward way on the wire: the low 32 bits are transmitted explicitly, and the high 32 bits are inferred. When computing the authentication tag, the kernel needs both halves concatenated in a specific order for the HMAC. authencesn handles this rearrangement by using the destination scatterlist as scratch space — temporarily shuffling bytes around before hashing.

This worked fine in 2011 because the only caller was the kernel’s internal xfrm layer, and the destination scatterlist was always a normal kernel buffer that authencesn legitimately controlled.

The Vulnerability: Three Changes, One Catastrophe

In 2015, AF_ALG gained AEAD support through algif_aead.c. This opened authencesn — and every other AEAD template — to direct invocation from unprivileged userspace. At the same time, authencesn was updated to the new AEAD interface. But at this stage, AF_ALG still operated out-of-place: the source scatterlist (containing input data) and the destination scatterlist (where output goes) were separate. Page cache pages could end up in the source scatterlist via splice(), but only in a read role. The authencesn scratch writes went to the destination, which was the user’s buffer. Not yet exploitable.

Then in 2017, an optimization was committed to algif_aead.c (commit 72548b093ee3) to make AEAD decryption operate in-place. The idea was to avoid an extra copy: instead of keeping separate source and destination scatterlists, the code would copy the AAD and ciphertext into the RX buffer, and then chain the authentication tag pages from the TX scatterlist directly onto the end of the RX scatterlist using sg_chain(). It then set req->src = req->dst, making both the source and destination point to the same combined chain.

This is the moment the three pieces collide. When a user splices a file into the TX path of an AF_ALG socket, the page cache pages of that file land in the TX scatterlist. After the 2017 in-place optimization, those tag pages get chained into the RX (destination) scatterlist. And authencesn, which uses the destination as scratch space, now has page cache pages in its writable destination.

The result is a controlled, deterministic write into the kernel’s cached copy of any file the attacker can read. The AEAD operation fails (the fabricated ciphertext doesn’t authenticate), so the recvmsg() call returns an error. The caller sees an error. The kernel thinks nothing unusual happened. And four bytes in the page cache of the target file have been silently overwritten.

The Mechanics of the Write Primitive

When authencesn processes a decryption request, it reads the Extended Sequence Number bytes from the AAD field and writes them back to the destination at offset assoclen + cryptlen. This write is supposed to land in the caller’s buffer. With the 2017 in-place path, it can instead land in page cache pages belonging to a file on disk.

The attacker controls all three critical parameters:

The target file is determined by which file descriptor gets passed to splice(). Any file readable by the current user is in scope. This includes setuid binaries like /usr/bin/su, which is world-readable and setuid-root on essentially every mainstream Linux distribution.

The target offset within that file is determined by the splice() call parameters — the file offset, splice length, and assoclen value. By doing the math, the attacker can position the write at any 4-byte boundary within the file’s page cache.

The value being written comes from bytes 4–7 of the AAD that the attacker provides in sendmsg(). These bytes represent seqno_lo in the ESN rearrangement logic, and they’re written verbatim to the destination. The attacker writes whatever they want.

The write is reliable. There is no timing dependency, no race window to win. Every invocation writes exactly four bytes to exactly the specified offset. By iterating over a shellcode payload in four-byte chunks, the attacker can overwrite arbitrarily large regions of the target file’s page cache.

The Exploit: 732 Bytes to Root

The published proof-of-concept targets /usr/bin/su by default, though it accepts any setuid binary as an argument. Here’s the flow at a high level:

First, the exploit opens an AF_ALG socket and binds it to authencesn(hmac(sha256),cbc(aes)). This is a standard AEAD template that exercises the vulnerable authencesn code path. No privileges are required — AF_ALG is available to all users in every mainstream distro’s default configuration.

Next, for each four-byte chunk of the shellcode payload, the exploit constructs a sendmsg() + splice() pair. The sendmsg carries the AAD with the desired four bytes in positions 4–7. The splice delivers pages from /usr/bin/su’s page cache as the ciphertext. The AEAD parameters are chosen so that the scratch write lands at the right offset within su’s .text section.

Each recv() call triggers the decryption attempt. Inside authencesn, the kernel reads the ESN bytes and writes seqno_lo across what it believes is its output buffer — but is actually a page cache page belonging to /usr/bin/su. The HMAC verification then fails, recvmsg() returns EBADMSG, and nothing looks alarming. Repeat for each four-byte chunk until the shellcode is fully written.

Finally, the exploit calls execve(“/usr/bin/su”). The kernel loads the binary from the page cache. The page cache version now contains the injected shellcode. Because su is setuid-root, the shellcode runs as UID 0. The attacker has root.

Affected Systems

Copy Fail affects Linux kernels built since the 2017 in-place optimization commit. Practically, this means: