CopyFail Is a 732-Byte Root Exploit for Every Linux Box Since 2017. The Disclosure Might Be Worse Than the Bug.

# CopyFail Is a 732-Byte Root Exploit for Every Linux Box Since 2017. The Disclosure Might Be Worse Than the Bug.

There's a new Linux local privilege escalation in town, and it's not playing by the usual rules. Most kernel bugs need a race window, or a specific offset, or some other condition that gives defenders a sliver of hope. CopyFail — CVE-2026-31431 — needs none of that. It's 100% reliable, works on every mainstream distribution shipped since 2017, and the proof-of-concept fits in a tweet-sized Python script. If you can run Python on a Linux box, you can get root. Period.

The researchers at Xint Code (Theori) found a logic bug in the kernel's crypto: aead implementation — specifically the algif_aead module that ships enabled by default in essentially every distro. A 2017 in-place optimization created a path where page-cache pages could end up in a writable destination scatterlist. Chain that through AF_ALG sockets and sendmsg/recvmsg, and you get a 4-byte page-cache write to any setuid binary. Run the 732-byte script, wait a moment, su, and you're root.

They demoed it on Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, and SUSE 16 — all with the exact same unmodified binary. Same script, four distributions, four root shells. The video is as impressive as it is nauseating.

The Bug Is Bad. The Process Is Worse.

Here's where it gets genuinely infuriating. The researchers published the exploit publicly on April 29, 2026. The problem? Major Linux distributions hadn't shipped the fix to their users yet. Gentoo developer Sam James posted to oss-security the next day with a tone you don't often see in the usually staid world of kernel security mailing lists: this was a disaster.

The HN thread on the disclosure failure is currently at 356 points and 286 comments, and the consensus from actual distro maintainers is brutal. The exploit was shared with the world before distributions had patches ready for their users. Shared hosting providers, Kubernetes clusters, CI runners — all sitting exposed with no fix available because the coordination layer between "patch landed in upstream kernel" and "distros can actually ship it" apparently doesn't exist.

Who Warns the People Who Ship the Kernels?

The structural problem here is genuinely shocking. Google's Project Zero has a well-defined disclosure policy: 90 days to fix, plus 30 days after the patch lands before public disclosure. That gives vendors time to prepare, test, and ship. The Linux kernel? There is no equivalent coordination channel between the upstream kernel security team and downstream distribution maintainers.

As one HN commenter put it: "the reporter should not be the one responsible for reporting separately to every single downstream of the thing they found a vuln in." The kernel security team is in a far better position to coordinate with distro security folk than individual researchers are. But that communication channel either doesn't exist or failed so completely that Gentoo found out about a 9-year-old critical LPE the same way the rest of us did: from a slick website with a "curl | python3" one-liner.

What This Actually Means for You

If you run multi-tenant Linux hosts, Kubernetes clusters, CI runners, or any cloud SaaS that executes user code: this is a drop-everything-and-patch moment. The mitigation is straightforward — update your kernel, or disable the algif_aead module if you can't patch immediately:

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

For the vast majority of systems, disabling algif_aead breaks nothing measurable. It doesn't affect dm-crypt/LUKS, OpenSSL, SSH, or kernel keyring crypto — those all use the in-kernel crypto API directly. What it breaks is userspace specifically configured to route crypto through AF_ALG, which is approximately nobody in production.

Container and sandbox environments should additionally block AF_ALG socket creation via seccomp regardless of patch state. If you give users containers and you haven't done this, fix it today.

The Bigger Picture

CopyFail isn't just a bad bug. It's a stress test of Linux security culture, and the results are mixed at best. The fact that a single 2017 optimization introduced a silent, universal LPE that sat undetected for nine years is one kind of problem. The fact that when it was finally found, the ecosystem had no mature process to get fixes to users before the exploit went public is another kind entirely.

We've spent years laughing at Microsoft Patch Tuesday and Apple's "security updates" that ship on a schedule. But at least they have a schedule. At least there's a pipeline. Linux has the most critical infrastructure in the world running on it, and its vulnerability disclosure pipeline appears to rely on researchers individually remembering to CC the right distro mailing lists.

The researchers did their job. They found a spectacular bug and they documented it beautifully. The kernel maintainers did their job — the patch landed in mainline. But somewhere between "patch exists" and "users are protected," the process fell apart. And when the gap between those two things is measured in exploited shared hosting providers, "someone should really fix the process" starts to sound a lot like "we need a new process."

I'll be patching my systems tonight. You should too.

copy.fail · GitHub: theori-io/copy-fail-CVE-2026-31431 · HN: Original disclosure · HN: Disclosure failure discussion