CVE-2026-31431 Copy Fail, Linux Kernel Root Exploit

CVE-2026-31431, widely known as Copy Fail, is a high-severity local privilege escalation vulnerability in the Linux kernel. It allows an unprivileged local user to gain full root access on almost every major Linux distribution shipped since 2017. A short, reliable Python script is enough to trigger it.

The flaw sits in the kernel’s cryptographic subsystem (algif_aead and the authencesn template). By combining AF_ALG sockets with the splice() system call, an attacker can perform a controlled 4-byte write into the page cache of any readable file. Because the page cache is shared across the system, the same technique also works across container boundaries.

Key Facts

• CVSS 3.1 score: 7.8 (High)
• Attack vector: Local
• Privileges required: Low (any unprivileged user)
• Affects: Linux kernels from 4.14 (2017) until the April 2026 patches
• Reliability: Deterministic — no race conditions
• Impact: Root privilege escalation + potential container escape
• Status: Actively exploited; added to CISA’s Known Exploited Vulnerabilities catalog

What Exactly Is CVE-2026-31431?

The official kernel description is short:

In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead – Revert to operating out-of-place. This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.

In plain language: a 2017 performance optimization made AEAD operations run “in-place.” When a user splices a regular file into an AF_ALG socket, the kernel places references to that file’s page-cache pages into a writable scatterlist. The authencesn algorithm then performs a small scratch write that lands inside those pages.

The kernel never marks the modified page as dirty. The file on disk stays untouched, so ordinary checksum tools miss the change. Every subsequent read or execution of that file, however, uses the corrupted in-memory version.

Why the Bug Is Especially Dangerous

• No race condition — the write is deterministic.
• Works on any readable file — including setuid binaries such as /usr/bin/su, sudo, or passwd.
• Stealthy — on-disk integrity checkers see nothing wrong.
• Crosses containers — the page cache is shared by the host and all containers on the same node.
• Tiny exploit — a 732-byte Python script using only the standard library is enough.

Researchers at Theori / Xint demonstrated the same script working on Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, and SUSE 16 without any modification.

Who Is Affected?

Virtually every mainstream Linux distribution that shipped a kernel built between August 2017 and the April 2026 patches is affected. Confirmed examples include:

Distribution	Example Kernel Version
Ubuntu 24.04 LTS	6.17.0-1007-aws
Amazon Linux 2023	6.18.8-9.213.amzn2023
RHEL 10.1	6.12.0-124.45.1.el10_1
SUSE 16	6.12.0-160000.9-default
Debian, Fedora, Arch, Rocky, Alma, Oracle Linux	Any unpatched kernel ≥ 4.14

Embedded systems, cloud images, Kubernetes nodes, CI runners, and multi-tenant hosts are all in scope. WSL2 is also affected because it runs a real Linux kernel.

Systems that never load the algif_aead module or have it blacklisted are not vulnerable.

How the Attack Works (High-Level)

1. The attacker opens an AF_ALG socket and binds to the authencesn(hmac(sha256),cbc(aes)) algorithm.
2. Using splice(), the attacker feeds pages from a target file (for example a setuid binary) into the socket.
3. The in-place AEAD path places those page-cache pages into the writable destination scatterlist.
4. The authencesn code performs a 4-byte scratch write of the sequence-number field into that scatterlist.
5. The attacker controls the exact offset and the 4-byte value written.
6. After enough controlled writes, the in-memory image of a setuid binary contains attacker-controlled code.
7. When the binary is executed, the kernel grants root privileges because the setuid bit is still set on the on-disk inode.

The same primitive can also corrupt /etc/passwd or shared container layers.

Impact on Real Environments

• Shared servers and jump hosts — any user becomes root.
• Kubernetes / container platforms — a compromised pod can corrupt host binaries or shared layers, leading to node takeover.
• CI/CD runners — a malicious pull-request can root the runner.
• Cloud multi-tenant workloads — tenant code can escape to the host.
• File-integrity monitoring — tools that only check on-disk content miss the attack.

Because the change lives only in the page cache, a simple reboot or echo 3 > /proc/sys/vm/drop_caches clears the corruption. The root shell obtained before that point is real.

How to Fix CVE-2026-31431

Permanent Fix (Recommended)

Update the kernel to a version that includes the upstream fix (commit a664bf3d603d or equivalent backports).

• Ubuntu / Debian: sudo apt update && sudo apt upgrade then reboot.
• RHEL / Rocky / Alma: sudo dnf update kernel then reboot.
• SUSE: apply the relevant SUSE security update and reboot.
• Amazon Linux: sudo dnf update then reboot.

Fixed stable versions include (among others) 5.15.204, 6.1.170, 6.6.137, and later mainline releases.

Temporary Mitigation (Until You Can Reboot)

Disable the vulnerable module:

Bash

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

This has negligible impact for most systems. SSH, LUKS, kTLS, IPsec, and normal OpenSSL usage do not rely on the AF_ALG userspace interface.

For untrusted workloads, also block AF_ALG socket creation with seccomp filters.

Detection and Verification

• Check whether the module is loaded: lsmod | grep algif_aead
• Look for the config: grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)
• After applying the mitigation, verify the module cannot be loaded.
• Public non-destructive detectors exist that only touch a temporary file in /tmp.

FAQ – Common Questions About CVE-2026-31431

Is this bug remote?
No. It requires local code execution as an unprivileged user.

Does it survive a reboot?
No. The corruption is only in the page cache. A reboot or dropping caches restores the original file contents.

Can it escape containers?
Yes. Because the page cache is shared, a container can corrupt host files or shared layers.

Will disabling algif_aead break my system?
For the large majority of servers and desktops, no measurable impact. Only applications that deliberately use the AF_ALG userspace crypto interface are affected.

Is there a public exploit?
Yes. A 732-byte Python proof-of-concept was released at the same time as the public disclosure. It is intended for defensive testing only.

When was the bug introduced?
The problematic in-place optimization landed in 2017 (commit 72548b093ee3). The vulnerable combination of that change with authencesn’s scratch write existed for nearly nine years.

What should I do right now?

1. Apply the temporary module blacklist if a kernel update is not immediately available.
2. Schedule a kernel update and reboot as soon as practical.
3. Prioritize multi-tenant hosts, Kubernetes nodes, and CI runners.

Final Recommendation

CVE-2026-31431 is a clean, reliable, and widely present privilege-escalation bug. Because a public exploit is available and CISA has confirmed active exploitation, every Linux administrator should treat it as high priority.

Patch the kernel, or at minimum disable the algif_aead module today. Once the system is updated and rebooted, the temporary mitigation can be removed.

Staying current with kernel security updates remains the most effective defense against this class of long-lived logic flaws.

References

• https://copy.fail/#exploit
• https://xint.io/blog/copy-fail-linux-distributions
• https://github.com/JuanBindez/CVE-2026-31431

Read more my article, find out and visit my website (Nomatali). Thank you