CVE-2026-31431 (Copy Fail): 9-Year-Old Linux Kernel Flaw Gives Root on Every Major Distro

What is Copy Fail?

Copy Fail (CVE-2026-31431) is a high-severity local privilege escalation vulnerability in the Linux kernel with a CVSS score of 7.8. Discovered by Theori researcher Taeyang Lee using the AI-powered Xint Code platform, this flaw has been silently present in every major Linux distribution since August 2017 — a full nine years undetected.

The vulnerability resides in the kernel's cryptographic subsystem, specifically in the algif_aead module. A logic flaw introduced during a 2017 in-place optimization allows an unprivileged local user to write four controlled bytes into the page cache of any readable file on the system. In practice, a 732-byte Python script can modify /etc/passwd in the page cache to change a user's UID to 0 (root), then execute su to gain a full root shell.

No race condition. No kernel address leak. No special configuration. Straight-line logic flaw with near-100% reliability across distributions.

How Does the Exploit Work?

The exploit chain involves four key steps:

1. Open an AF_ALG socket — Bind to the authencesn(hmac(sha256),cbc(aes)) algorithm, which is available to unprivileged users.
2. Send AAD via sendmsg — Send 8 bytes of Associated Authenticated Data inline with MSG_MORE flag set.
3. Splice a target file's page — Use splice() to deliver a page-cache reference of the target file (e.g., /etc/passwd) into the crypto operation's scatterlist.
4. Trigger the write — Call recv() to drive the AEAD decryption. The authentication check fails with EBADMSG, but the scratch write into the page cache has already landed.

The result: the user's UID field in the cached version of /etc/passwd is overwritten from 1000 to 0000. The user then runs su with their own password, and PAM validates against /etc/shadow (untouched) while setuid() reads the corrupted UID of 0 from the page cache. Root achieved.

Which Linux Distributions Are Affected?

Every Linux kernel built since the 2017 optimization commit is vulnerable. Confirmed affected distributions include:

• Ubuntu — All releases before 26.04 (Resolute): 24.04 LTS, 22.04 LTS, 20.04 LTS, 18.04, 16.04
• Red Hat Enterprise Linux (RHEL) — All current versions, patches still pending
• Amazon Linux — All versions since 2017
• SUSE Linux Enterprise — All versions since 2017
• AlmaLinux — All supported releases
• Rocky Linux — All supported releases
• CloudLinux — Versions 7h, 8, 9, and 10
• Debian — Affected versions since 2017

Not affected: Ubuntu 26.04 (Resolute) and later kernels ship with the fix already applied.

The Container Threat

Copy Fail is especially dangerous in containerized and multi-tenant environments. The Linux page cache is shared between containers and the host kernel. A write from inside one container affects the host page cache, and therefore every other tenant on that host.

CERT-EU has specifically recommended prioritizing patches on Kubernetes nodes and CI/CD runners. OVHcloud has already released a DaemonSet for rapid mitigation on their managed Kubernetes clusters.

This vulnerability reinforces what security professionals have long said: containers are not a security boundary. If your isolation strategy relies on namespaces alone without a VM or hardware boundary, your threat model needs updating.

How to Check If Your System Is Vulnerable

A detection script is available. Run the following to test your system:

python3 test_cve_2026_31431.py
# Exit code 0 = not vulnerable
# Exit code 2 = vulnerable
# Exit code 1 = test error

The test script checks whether the AF_ALG socket and the authencesn algorithm are reachable, creates a sentinel file, attempts the page-cache write, and verifies if the marker landed.

You can also check if your kernel package includes the fix by querying your package manager's changelog:

On RHEL/AlmaLinux/Rocky/CloudLinux:

rpm -q --changelog kernel | grep CVE-2026-31431

On Ubuntu/Debian:

apt changelog linux-image-$(uname -r) 2>/dev/null | grep CVE-2026-31431

If no results are returned, your system is likely still vulnerable.

How to Fix / Mitigate

Option 1: Apply Kernel Updates (Recommended)

The upstream fix (mainline commit a664bf3d603d) reverts the 2017 in-place AEAD optimization to out-of-place operations, preventing page-cache pages from ending up in writable scatterlists.

Ubuntu: The Ubuntu Security Team has released a kmod package update that disables the affected module. If unattended-upgrades is enabled (default since 16.04), the patch will auto-apply within 24 hours. Reboot after updating.

AlmaLinux: Patched kernels are available in the testing repository:

dnf update 'kernel*' --enablerepo=almalinux-testing
reboot

CloudLinux: KernelCare livepatches are being rolled out. For KernelCare subscribers, no action is needed — the patch applies automatically without reboot:

kcarectl --update
kcarectl --info | grep CVE-2026-31431

RHEL: Patches are not yet available from Red Hat at the time of writing. Apply the mitigation below until an official errata is released.

Option 2: Disable algif_aead Module (Immediate Mitigation)

On distributions where algif_aead is a loadable module (Ubuntu/Debian):

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

This prevents the vulnerable interface from loading. It does not affect dm-crypt/LUKS, kTLS, IPsec, SSH, OpenSSL, or GnuTLS. Only applications that explicitly use the afalg engine or bind AEAD sockets directly via AF_ALG will be impacted (rare in most deployments).

You can check for affected applications with: lsof | grep AF_ALG

Option 3: Boot-time Blacklist (For RHEL-family Distros)

Important: On RHEL, AlmaLinux, Rocky Linux, and CloudLinux, the algif_aead module is built into the kernel (CONFIG_CRYPTO_USER_API_AEAD=y). The modprobe workaround does not work on these distributions — it runs without errors but leaves the system unchanged, giving a false sense of security.

Instead, use the grubby boot-time blacklist:

grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
reboot

After reboot, confirm the parameter is active:

cat /proc/cmdline | grep algif_aead_init

The AI Angle: How Copy Fail Was Discovered

What makes Copy Fail historically significant isn't just the vulnerability itself — it's how it was found.

Taeyang Lee of Theori used Xint Code, an LLM-native static analysis platform, to scan the Linux kernel's crypto subsystem. The operator prompt was minimal: examine all codepaths reachable from userspace syscalls, with a note about splice() delivering page-cache references to crypto scatterlists.

One prompt. One hour of automated scanning. One critical zero-day that had been hiding for nine years.

Theori is not an unknown player — as part of team MMM, they've won DEF CON CTF nine times and placed third in DARPA's AI Cyber Challenge finals. Xint Code had already found critical zero-day RCE vulnerabilities in Redis, PostgreSQL, and MariaDB before this.

The broader trend is unmistakable. Bug report volumes have surged in recent months. Microsoft's recent Patch Tuesday was the second largest ever. Trend Micro's Zero Day Initiative head Dustin Childs attributes the increase to security teams using AI to hunt bugs.

As Bugcrowd's David Brumley put it: the entire vulnerability ecosystem — patch cycles, budgets, CVE prioritization — was built on the assumption that finding a kernel-grade bug is expensive. That assumption is now false. The cost of discovering critical vulnerabilities has dropped dramatically, and the implications apply equally to defenders and attackers.

Comparison to Dirty Pipe (CVE-2022-0847)

Copy Fail shares the same class of primitive as Dirty Pipe — both exploit the Linux page cache to achieve privilege escalation. Dirty Pipe allowed unprivileged users to splice data into read-only files. Copy Fail does the same thing through the crypto subsystem's AEAD operations.

Key differences: Copy Fail has no race condition requirement, needs no kernel offset, and works identically across all major distributions. The same 732-byte script roots Ubuntu, RHEL, Amazon Linux, and SUSE without modification.

Timeline

• August 2017 — Vulnerable optimization introduced in Linux kernel crypto subsystem
• March 23, 2026 — Taeyang Lee reports vulnerability to Linux kernel security team
• April 22, 2026 — CVE-2026-31431 identifier assigned
• April 29, 2026 — Public disclosure by Xint.io / Theori
• April 30, 2026 — Ubuntu releases kmod mitigation; AlmaLinux ships testing patches; CERT-EU advisory published
• May 1-2, 2026 — CloudLinux KernelCare livepatches rolling out; vendor patches ongoing

Sources

• Xint.io — Copy Fail: 732 Bytes to Root on Every Major Linux Distribution (Original Disclosure)
• Bugcrowd — What We Know About Copy Fail
• The Hacker News — New Linux Copy Fail Vulnerability
• Ubuntu — Fixes Available for CVE-2026-31431
• AlmaLinux — Copy Fail Patch Ready for Testing
• CloudLinux — CVE-2026-31431 Kernel Update
• CERT-EU — Security Advisory 2026-005
• The Register — Linux Cryptographic Code Flaw
• Infosecurity Magazine — Zero-Day Flaw in Linux Kernel Found by AI
• NVD — CVE-2026-31431