CVE-2026-31431 “Copy Fail”: The Linux Kernel Bug That Had Everyone Scrambling in 2026

How a 9-year-old optimization turned into the most researched vulnerability of the year.

So here’s the thing about Linux kernel vulnerabilities—they usually fall into two camps. There are the messy ones that require winning race conditions, crashing things, and praying the timing works out (looking at you, Dirty Cow). And then there are the clean ones. The straight-line logic bugs that just work, every time, no drama.

Copy Fail is the second kind. And that’s exactly why it became the most researched CVE of 2026.

Let me walk you through what happened, why it matters, and what you actually need to do about it.

Why Copy Fail Broke Everyone’s Brain

When CVE-2026-31431 dropped on April 29, 2026, the security community went into overdrive. Not because it was a remote code execution (it’s not). Not because it affected some obscure embedded system (it affected basically everything). The frenzy happened because of three things that, combined, made this vulnerability uniquely terrifying:

The exploit fit in a tweet. Okay, not literally, but at 732 bytes, the Python proof-of-concept was absurdly small. No compiled payloads. No dependencies beyond Python 3.10’s standard library. No version-specific offsets or distribution-specific tweaks. The same script worked on Ubuntu, Amazon Linux, RHEL, and SUSE without modification.

The bug had legs. The vulnerability existed in Linux kernel versions 4.14 through 7.0-rc—that’s every major distribution shipped since 2017. Nearly a decade of kernels. Most organizations were running vulnerable systems somewhere in their infrastructure.

It was weirdly stealthy. Here’s the kicker: the exploit corrupted files in the kernel’s page cache—the in-memory representation—but never touched the actual disk. Your file integrity monitoring tools would see pristine checksums on disk while the running system happily executed malicious code.

Researchers from Theori’s Xint Code team discovered this gem, and they did it using AI-assisted vulnerability research. The bug sat at the intersection of three separate kernel changes that were each reasonable in isolation but catastrophic together. No human reviewer connected the dots for nine years.

The Technical Breakdown: How We Got Here

Alright, let’s get into the weeds. Don’t worry—I’ll keep it digestible.

The Players

AF_ALG is a socket type that exposes the Linux kernel’s cryptographic subsystem to unprivileged userspace programs. Any user can open one, bind to a cipher, and perform encryption/decryption operations. No special permissions required—this is by design, used for things like disk encryption tools.

splice() is a system call that moves data between file descriptors without copying it. Instead of reading data into a buffer and writing it back out, splice passes page references directly. Efficient? Absolutely. The problem is it passes references to page cache pages—the kernel’s cached copies of files on disk.

algif_aead is the AF_ALG implementation for AEAD ciphers (Authenticated Encryption with Associated Data)—think GCM, CCM, and specifically for our story, authencesn.

authencesn sounds like someone fell asleep on their keyboard, but it’s actually an AEAD wrapper used by IPsec for Extended Sequence Number (ESN) support. It handles 64-bit sequence numbers for VPN connections.

The Bug

In 2017, commit 72548b093ee3 introduced an optimization to algif_aead. Instead of copying data between scatterlists (kernel data structures for I/O operations), the code switched to in-place processing. The kernel would copy some data, then chain remaining pages by reference using sg_chain().

Here’s the problem: when a user splices a file into an AF_ALG socket, the authentication tag portion of the AEAD input stays as direct references to page cache pages. The optimization then chains those page cache pages into the output scatterlist. Suddenly, those read-only cached file pages are part of a writable data structure.

But that’s just the setup. The trigger is authencesn.

This algorithm, in doing its ESN byte rearrangement for HMAC computation, writes 4 bytes at offset assoclen + cryptlen into the destination buffer. That position is meant to be scratch space—somewhere to temporarily store sequence number data.

scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 1);
// writes 4 bytes past the AEAD tag boundary

But in the in-place AF_ALG path, assoclen + cryptlen crosses from the legitimate output buffer into those chained page cache pages. The algorithm writes 4 bytes directly into the kernel’s cached copy of whatever file the attacker spliced in.

The HMAC verification fails as expected (the data is garbage), and recvmsg returns an error. But those 4 bytes? They stay written. The kernel never marks the page dirty for writeback, so the file on disk remains pristine. But the in-memory copy—the one every process reads from—is corrupted.

The Perfect Storm

This bug required three pieces to click together:

1. The 2011 addition of authencesn, using destination scratch space (harmless in original context)
2. The 2015 AF_ALG AEAD support with splice paths (separate scatterlists, still safe)
3. The 2017 in-place optimization (chains page cache pages into writable scatterlist)

Each change made sense individually. No one connected authencesn’s scratch writes to the splice path’s page cache references. The vulnerability existed at their intersection, silently exploitable for almost a decade.

Exploitation: Four Syscalls to Root

The public exploit targeting /usr/bin/su demonstrates how clean this vulnerability is. No memory corruption. No heap spraying. No race conditions.

Just four syscalls: socket, splice, sendmsg, recvmsg.

The Attack Steps

Step 1: Setup. Create an AF_ALG socket and bind to authencesn(hmac(sha256),cbc(aes)). Set a key. Accept a request socket. This requires zero privileges.

s = socket.socket(38, 5, 0)  # AF_ALG, SOCK_SEQPACKET
s.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))

Step 2: Construct writes. For each 4-byte chunk of payload, craft a sendmsg() with AAD bytes 4-7 containing the data you want to write. The splice() pulls page cache pages from /usr/bin/su into the crypto pipeline.

Step 3: Trigger. Call recv() to trigger decryption. The authencesn algorithm writes seqno_lo (those 4 bytes from the AAD) into the page cache. The HMAC fails, recvmsg returns an error code, but the corruption persists.

Step 4: Execute. After staging your shellcode into /usr/bin/su‘s cached pages, run su. The kernel loads from the (now malicious) page cache. Since su is setuid-root, your injected code runs with UID 0.

You have root.

What Makes This Dangerous

Reliability. Dirty Cow needed to win races. Dirty Pipe required precise pipe buffer manipulation. Copy Fail? It just works. The logic is deterministic—no timing windows, no crashes, no multiple attempts.

Cross-container impact. The page cache is shared across all processes on a host, including containers. An attacker with a foothold in one pod can corrupt SUID binaries for the entire node. This isn’t just local privilege escalation; it’s a container escape primitive.

Stealth. The kernel doesn’t mark corrupted pages as dirty. On-disk checksums remain valid. Traditional file integrity monitoring completely misses this attack.

Portability. The same 732-byte Python script works across Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, and SUSE 16. No modifications.

Detection: Catching Copy Fail in Action

Here’s the good news: detection is actually straightforward. The attack has a signature.

What to Look For

The exploit requires creating an AF_ALG socket with SOCK_SEQPACKET type and binding to an AEAD algorithm. This is uncommon. Most legitimate AF_ALG usage (disk encryption tools like cryptsetup, systemd-cryptsetup, veritysetup) uses SOCK_DGRAM or accesses hashing/symmetric ciphers, not AEAD.

Any unexpected process creating an AF_ALG SEQPACKET socket deserves investigation.

Falco/Sysdig Detection Rule

Sysdig’s Threat Research Team published a Falco rule that flags exactly this pattern:

- rule: Unexpected Process Using Kernel AEAD Crypto Socket
  desc: >
    Detects creation of an AF_ALG SEQPACKET socket from a process
    outside the known disk-encryption toolchain.
  condition: >
    successful_af_alg_seqpacket_socket and
    not proc.name in (known_af_alg_binaries)
  output: >
    Unexpected process %proc.name opened AF_ALG AEAD kernel crypto socket
  priority: CRITICAL
  tags: [cve, CVE-2026-31431, MITRE_T1068]

The known_af_alg_binaries list includes legitimate users: cryptsetup, systemd-cryptsetup, veritysetup, integritysetup, kcapi-* utilities.

Kernel-Level Detection

If you’re monitoring syscall patterns, watch for:

• Unprivileged processes opening socket(AF_ALG, SOCK_SEQPACKET, 0)
• splice() calls feeding file descriptors into AF_ALG sockets
• Processes that aren’t crypto utilities using setsockopt() with ALG_SET_KEY or ALG_SET_AEAD_AUTHSIZE

Log Aggregation

In your SIEM, query for processes creating network sockets with domain 38 (AF_ALG’s numeric value) and type 5 (SOCK_SEQPACKET). Combined with user context (unprivileged users shouldn’t be doing kernel crypto operations), this provides a clear detection signal.

Patching and Mitigation: What Actually Works

Onto the part you actually need to implement.

The Official Fix

The upstream patch (commit fafe0fa2995a) is wonderfully blunt: it reverts the in-place optimization. The kernel now copies data between scatterlists again. The commit message is direct: “There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings.”

Sometimes the best fix is the one you already deleted.

Fixed kernel versions:
– Linux 7.0 and later
– Linux 6.19.12 and later
– Linux 6.18.22 and later
– Various LTS backports (5.15.x, 5.10.x, 4.x) depending on distribution

Distribution Updates

All major distributions released patched kernels:

Apply kernel updates and reboot. There’s no way around the reboot—running systems won’t magically load the new kernel.

Immediate Mitigation (If Patching Takes Time)

If you can’t immediately patch, block the vulnerable module:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

This prevents the algif_aead module from loading. Most applications will fall back to userspace crypto libraries, though some high-performance crypto applications might notice degraded throughput.

Ubuntu even pushed this mitigation through the kmod package as an automatic stopgap, though you should still apply kernel updates.

Container Considerations

If you’re running Kubernetes:

1. Patch the host kernel. The vulnerability exists in the host kernel; container escape means any pod could potentially compromise the entire node.

2. Restrict AF_ALG via seccomp. Add a seccomp profile that denies socket(AF_ALG, ...) for workloads that don’t need kernel crypto.

3. Use Pod Security Standards. Restricted pods shouldn’t have the CAP_SYS_MODULE capability, but the key protection is host kernel patching.

4. Watch for part 2 of the Theori research. They demonstrated container escape scenarios that go beyond the local privilege escalation.

The Bigger Picture: Why This Matters

Copy Fail teaches us several uncomfortable lessons.

Optimization Bugs Are the Worst

The in-place optimization saved some memory copies. A reasonable micro-optimization. But it created a decade-long window where page cache pages—read-only cached file contents—became writable through a cryptographic API meant for user data.

Performance optimizations that touch security boundaries deserve extreme scrutiny. The kernel review process caught obvious issues. It didn’t catch the interaction between three separate changes.

Detection-Based Security Has Limits

Your file integrity monitoring, your on-disk checksums, your “has this binary changed” checks—they all miss page cache corruption. The file never changes on disk. Only the cached representation in memory is modified.

Runtime detection of anomalous behavior (like unexpected AF_ALG socket creation) is your only real defense when the vulnerability evades static analysis.

AI-Assisted Research Works

Theori used their Xint Code tool—an AI-powered vulnerability scanner—to find this. A human researcher had the insight about page cache provenance, but the AI scaled the search across the entire crypto subsystem.

A researcher-guided prompt identified the attack surface. The scanner found the vulnerability in about an hour. This is the future of vulnerability research: human intuition plus AI scale.

Final Thoughts

Copy Fail (CVE-2026-31431) became the most researched CVE of 2026 because it hit the trifecta: widespread impact, trivial exploitation, and operationally significant stealth. The 9-year window, the 732-byte exploit, the cross-container implications—it all combined into a vulnerability that nobody could ignore.

The fix is straightforward: update your kernels, reboot, and move on. But the lessons linger. Optimization decisions have long tails. Defense-in-depth means runtime monitoring, not just file integrity checks. And the next decade-old kernel bug is probably already there, waiting for someone to connect the dots.

Patch your systems. Check your logs. And maybe keep a closer eye on those “harmless” optimizations.

For more technical details, see the original Theori writeup at xint.io/blog/copy-fail-linux-distributions and the proof-of-concept at github.com/theori-io/copy-fail-CVE-2026-31431.