Copy Fail isn't the worst Linux bug that was ever discovered, but it's more than bad enough. This local privilege escalation (LPE) flaw enables an unprivileged local user to easily obtain root. That's never good news. Worse still, this isn't a theoretical bug. Both Microsoft and the Cybersecurity and Infrastructure Security Agency (CISA) both report spotting attacks in the wild. Oh joy!

Theori and Xint Code AI-assisted security researchers discovered CVE‑2026‑31431, a logic flaw in the Linux kernel’s crypto subsystem. This hole enabled a tiny 732‑byte Python script to become a reliable root exploit across major distributions, including Ubuntu, Amazon Linux, RHEL, SUSE, and others.

The bug sits in the authencesn cryptographic template and the AF_ALG userspace crypto socket path. The problem was that a design change made in 2017 allowed page‑cache pages from read‑only files to be treated as writable buffers.

By abusing this path, an unprivileged user can make the kernel perform a controlled 4‑byte overwrite in the page cache of any file they can read, such as a setuid‑root binary, such as /usr/bin/su.

Adding insult to injury, because the corruption only touches the in‑memory page cache and never marks the underlying file as dirty, on‑disk checksums and standard integrity tools see a clean file even while the live system is executing attacker‑supplied code.

The proof‑of‑concept exploit published by the researchers uses only standard Python 3.10 libraries and works unchanged on the four distributions they tested, turning a regular user shell into root in a single run. A demo showed the same script producing root shells on Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, and SUSE 16 in one continuous session.

Kernel privilege‑escalation bugs are not new. But the researchers argue that Copy Fail combines properties that make it unusually severe. Unlike race‑condition‑driven exploits such as 2016's Dirty COW or 2022's Dirty Pipe, Copy Fail is a straightforward logic bug with no timing window, no crash‑prone retry loop, and no per‑distro offsets.

Critically, the vulnerability requires only local code execution as a non‑privileged user. It doesn't need special kernel debugging options or pre‑existing exploitation primitives to successfully attack a system.

Worse still, the exploit primitive can work across containers. Since the page cache is shared across all of a host's processes, a compromised container can corrupt a host‑level setuid binary, allowing it to break out of Kubernetes or other multi‑tenant container platforms.

This is bad news with a capital B. 

The underlying error dates back over a decade. It's the result of three different Linux kernel changes, all of which were harmless by themselves. Together, they equaled trouble. 

First, support for the authencesn Authenticated Encryption With Associated Data (AEAD) algorithm used by IPsec ESP with extended sequence numbers landed in 2011. This enabled the caller’s destination buffer to be used as scratch space to reshuffle sequence number bytes for Hash-based Message Authentication Code (HMAC) processing.

Next, in 2015, the kernel added AEAD support to AF_ALG, the socket interface that exposes crypto operations to userspace. This change also refactored authencesn to a newer AEAD interface that writes four bytes past the nominal output buffer into what it assumes is expendable scratch. So far, so harmless.

The final deadly step came in 2017, when an optimization in algif_aead switched decryption to operate “in‑place,” chaining tag data from page‑cache‑backed file pages directly into the writable scatterlist and then setting the same list as both the source and destination for the crypto operation. Once that change shipped, authencesn’s four‑byte scratch write crossed the boundary into page‑cache pages of arbitrary readable files, turning the design quirk into a universal local privilege‑escalation bug.

Whoops!

The upstream fix removes the 2017 in‑place optimization and restores out‑of‑place operation for algif_aead, ensuring that page‑cache pages from splice() calls reside only in the source scatterlist, not the writable destination. This cleanly severs the path that allowed authencesn to scribble into cached file contents while leaving user‑visible crypto behavior intact.

Since then, distributions have raced to ship patched kernels that incorporate the upstream change. 

As of May 4th, here's the status of the major Linux distros.

Once you have the patch installed, reboot your system, and all should be well. Don't wait. Since the exploit is both trivial, tiny, and public, you can assume that weaponized scripts will quickly appear in real‑world attack chains.

Can't patch it yet? I recommend disabling the algif_aead module as a temporary mitigation.  That can be done by adding a modprobe rule that replaces the module with a no‑op and then unloading it from the running kernel:

bash

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf

sudo rmmod algif_aead 2>/dev/null

For most environments, this mitigation shouldn't hurt a bit. However, if you know you use AF_ALG, for example, with OpenSSL’s afalg engine, you should weigh the trade‑off between risk and performance. Since I think we can safely assume attacks are already underway, you should lock down my system right now. 

Noteworthy Linux and open-source stories:

If you’re a decision maker at your company, you need to be on the bleeding edge of, well, everything. But before you go signing up for seminars, conferences, lunch ‘n learns, and all that jazz, just know there’s a far better (and simpler) way: Subscribing to The Deep View.

This daily newsletter condenses everything you need to know about the latest and greatest AI developments into a 5-minute read. Squeeze it into your morning coffee break and before you know it, you’ll be an expert too.

Subscribe right here. It’s totally free, wildly informative, and trusted by 600,000+ readers at Google, Meta, Microsoft, and beyond.