This is a regular Linux server. No root access. No special privileges. The user you're looking at is uid 1001 — a totally normal account.

Watch what happens when I run a single Python script. 732 bytes. Standard library only. No compilation. No binary payloads.

That's a root shell. From an unprivileged user. On Ubuntu 24.04. The same script — no changes — also works on Amazon Linux, RHEL, and SUSE.

This is Copy Fail. CVE-2026-31431. A bug that lived silently in the Linux kernel for nine years.

Today we're doing a complete technical breakdown. We'll cover the kernel internals that made this possible, the exact sequence of commits that accidentally created the vulnerability, and why standard file integrity tools would have completely missed it — because this bug doesn't touch the disk at all.

There's a lot of depth here. Grab a coffee. By the end, you'll understand AF_ALG sockets, the Linux page cache, cryptographic scatterlists, and one of the most elegant — and terrifying — exploit chains in recent kernel history.

Let's go.

You've probably heard of Dirty Cow — CVE-2016-5195. Devastating privilege escalation, but it required you to win a race condition in the VM subsystem's copy-on-write path. It sometimes needed multiple retries. It sometimes crashed the machine.

Dirty Pipe — CVE-2022-0847 — was version-specific. You needed precise pipe buffer manipulation and it only worked on certain kernel versions.

Copy Fail has none of those caveats. It is a straight-line logic flaw. No racing. No retries. No version-specific offsets. No compilation. Same script. Every major distribution. Every time.

Here's what makes this especially nasty from a defense standpoint: the bug never touches the disk. The on-disk file is completely unchanged. If you were running tripwire, AIDE, or any file integrity monitor that checks SHA256 hashes of files on disk, it would report everything as clean.

What gets corrupted is the page cache — the in-memory representation of the file that the kernel hands to every process that reads or executes it. The page is never marked dirty for writeback. The kernel has no idea anything happened.

And because the page cache is shared across the entire host, including across container boundaries — this is also a container escape. We'll get to that in Part 2 of this series.

To understand Copy Fail, you need to understand two Linux kernel features that most developers have never touched.

The first is AF_ALG — the kernel crypto socket interface. It's a special socket type, address family 38, that exposes the kernel's cryptographic subsystem directly to unprivileged userspace. You can open an AF_ALG socket, bind it to any cryptographic algorithm — AES-GCM, HMAC-SHA256, or in our case, an AEAD mode called authencesn — and then send data through it to be encrypted or decrypted. All without root. All from a normal user account.

This is a legitimate feature. It exists so applications can do hardware-accelerated cryptography using kernel drivers without needing special privileges. But it also means any user can interact with the kernel's entire crypto subsystem.

The second piece is splice() — a Linux syscall designed for zero-copy data transfer. Normally when you move data between file descriptors, the kernel copies it through a userspace buffer. splice() skips that. It moves page references — pointers to the same physical memory pages — instead of copying bytes.

So if you splice from a file into a pipe, and then splice from that pipe into an AF_ALG socket, what ends up in the socket's input buffer are direct references to the kernel's page cache pages for that file. Not copies. The actual pages.

This is powerful and efficient. It's also the first half of our vulnerability. An unprivileged user can feed page cache pages — including pages from setuid binaries they can read but not write — directly into the crypto subsystem's input buffers.

Keep that mental model locked in. Page cache pages. By reference. In the kernel's scatterlist. That's the setup. The exploit is what happens when a crypto algorithm doesn't respect the boundary of where it's allowed to write within that scatterlist.

Now we get into the actual bug. For AEAD — Authenticated Encryption with Associated Data — decryption, the input format is: Associated Data, followed by ciphertext, followed by an authentication tag. The kernel's AF_ALG socket processes this in algif_aead.c.

In 2017, a performance optimization was added: instead of using separate source and destination scatterlists, algif_aead.c would do the operation in-place. It copies the AAD and ciphertext into the output buffer, but chains the authentication tag pages onto the end of the output scatterlist using sg_chain(). Then it sets req->src equal to req->dst. Both point to the same scatterlist.

The result: page cache pages from your target file are now sitting inside the writable output scatterlist. The only thing protecting them is an implicit assumption — that every AEAD algorithm will confine its writes to the portion it owns. The API doesn't enforce this. The documentation doesn't mandate it. It's a silent contract.

And one algorithm breaks it.

authencesn is an AEAD wrapper used by IPsec for Extended Sequence Number support. IPsec uses 64-bit sequence numbers to prevent replay attacks. These are split: a high half and a low half. The wire format only carries the low half — the high half is reconstructed on both ends.

For HMAC verification, authencesn needs to hash the sequence number in a specific order: high half first, low half appended at the end. To do this rearrangement, the kernel uses the destination scatterlist as scratch space — a temporary workspace for shuffling these bytes before computing the HMAC.

Call 3 is the bug. It writes 4 bytes at assoclen + cryptlen — which is past the end of the ciphertext, into the authentication tag region. In the vulnerable in-place design, that tag region contains page cache pages chained from the input. So this write lands directly on the kernel's cached copy of whatever file you spliced in.

The attacker controls three things completely:

Controlled 4-byte write. Arbitrary offset. Any readable file. From an unprivileged account. That's a complete, deterministic write primitive.

Here's what I find most fascinating about Copy Fail: no single commit is obviously wrong. The vulnerability emerges from the interaction between three separate changes made over six years by different developers solving different problems.

The exploit itself is conceptually clean. Four steps:

Notice: the kernel returns an error from recv() every single time. From the kernel's perspective, these are failed decryption attempts. No alarm is raised. No log entries about memory corruption. The 4-byte write happens silently, the HMAC check fails as expected, and execution continues normally.

The disk never changes. The page cache never gets flagged dirty. Standard monitoring sees nothing unusual. Only the in-memory execution environment is corrupted — and that's all you need.

The fix is elegant and correct: revert algif_aead.c to out-of-place operation. Remove the 2017 optimization entirely.

req->src now points to the TX scatterlist — which may contain page cache pages from splice(). req->dst points to the RX scatterlist — the user's output buffer. The sg_chain mechanism is gone. Page cache pages are no longer in the writable destination. authencesn's scratch write can't reach them.

Any kernel from 2017 onward running an unpatched algif_aead is potentially vulnerable. Kernel lines 6.12, 6.17, and 6.18 all confirmed.

The researcher behind this, Taeyang Lee from Theori, had prior experience with kernelCTF research and had already mapped the AF_ALG attack surface. He had a hypothesis: the splice() path that delivers page cache references into the crypto subsystem might be an underexplored source of vulnerabilities if any algorithm didn't respect page provenance.

He pointed Xint Code — an AI security research tool — at the Linux crypto/ subsystem, with a simple operator prompt:

One hour later, Copy Fail was the highest-severity output. The AI connected the splice() input path in algif_aead.c, the in-place optimization, and authencesn's out-of-bounds scratch write — a cross-file, multi-year connection that a human might not have made without deep familiarity with all three subsystems simultaneously.

This matters for the future of security research. The insight — the hypothesis about page provenance in the splice path — came from a human with deep domain knowledge. The scaling across an entire subsystem, connecting behaviors in files that were never designed to interact, came from AI. The combination found something that had been hiding for nine years.

The blog post notes the same scan also found other high-severity vulnerabilities still in responsible disclosure. We'll be watching for those.

Let's bring it together. Copy Fail — CVE-2026-31431 — is a logic bug born from three independent kernel changes made between 2011 and 2017:

Each change was individually reasonable. Together, they created a deterministic, portable, stealthy, 4-byte controlled write into the page cache of any readable file. From any unprivileged account. On essentially all Linux distributions since 2017.

Patch your kernels. Disable algif_aead if you don't need it. And remember — your on-disk file hashes mean nothing if the page cache is compromised.

Part 2 is coming: how Copy Fail escapes every major cloud Kubernetes platform. We'll walk through how the shared page cache means a container workload can corrupt binaries on the host — and what that means for your cloud security posture.

If you want to go deeper on the kernel internals we covered today — AF_ALG, scatterlists, splice() — I'll put resources in the description. Links to the original Xint blog post, the GitHub PoC repo, and the kernel commit that introduced the 2017 in-place optimization.

If this was useful, subscribe, and drop a comment — particularly if you're in cloud security or kernel development. I want to know what questions you have heading into Part 2.

See you in the next one.