CVE-2026-31431

Overview

CVE-2026-31431, nicknamed "Copy Fail," is a local privilege escalation vulnerability in the Linux kernel's algif_aead module — the AEAD (Authenticated Encryption with Associated Data) socket interface of the kernel's userspace crypto API (AF_ALG). Discovered by Theori researcher Taeyang Lee using the AI-assisted Xint Code scanning tool, the flaw lets any unprivileged local user gain root access within seconds. A working 732-byte Python proof-of-concept exploit runs unmodified against Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, and SUSE 16 — every mainstream Linux distribution built since 2017 is affected.

The vulnerability was introduced by a 2017 in-place processing optimization (commit 72548b093ee3) and fixed by reverting that change (commit a664bf3d603d). The name "Copy Fail" reflects the flaw's essence: a kernel copy operation that should not modify its source ends up writing into the page cache of privileged binaries.

What is the Linux Kernel?

The Linux kernel is the foundational software layer between hardware and user-space programs, running in every major Linux distribution — enterprise servers (RHEL, Ubuntu, SUSE), cloud instances on AWS, GCP, and Azure, Android smartphones, IoT devices, and container runtimes. As the most privileged code on any Linux system, a privilege escalation flaw in the kernel allows any local user — a restricted shell account, a compromised web application, or code running in a container — to obtain complete control of the host. Because every major distribution ships affected kernel builds, "Copy Fail" has an unusually broad blast radius compared to application-level CVEs.

Affected Versions

The vulnerability was introduced in July 2017 via commit 72548b093ee3. Every Linux kernel from 4.14 onward through pre-7.0 is affected.

Affected distributions (at time of public disclosure on April 29, 2026): Ubuntu 24.04 LTS, Amazon Linux 2 and 2023, RHEL 10.1, SUSE 16, AlmaLinux, Rocky Linux, Debian, and derivatives. CERT-EU noted that as of the disclosure date, no major distribution had yet shipped a fixed kernel package.

Technical Details

Root Cause: Page Cache Pages in the Writable Scatterlist

The AF_ALG interface exposes kernel cryptographic functions to userspace via sockets. In 2017, commit 72548b093ee3 introduced an in-place processing optimization for AEAD operations in algif_aead: rather than always copying data to a new buffer, it allowed page-cache pages to be placed directly into a writable destination scatterlist.

The authencesn cryptographic template, when operating in AEAD mode, writes a small "scratch" block to a fixed offset in the destination scatterlist. When the destination scatterlist holds a page-cache page (a kernel-managed in-memory cache of a file on disk), that scratch write lands directly in memory backing a readable file. An attacker can steer this write at the page-cache copy of any setuid binary — such as /usr/bin/su — by chaining AF_ALG socket operations with splice().

Exploitation Mechanism

The exploit:

1. Opens an AF_ALG AEAD socket and sets up an authencesn algorithm session
2. Uses splice() to map the page-cache pages of a target setuid binary (e.g., /usr/bin/su) into the socket's scatterlist
3. Triggers the AEAD operation, causing authencesn's scratch write to corrupt exactly 4 bytes within that page-cache page
4. Carefully chosen target bytes overwrite instruction bytes in the setuid binary's in-memory representation, redirecting execution to attacker-controlled shellcode
5. Executes the now-modified in-memory copy of /usr/bin/su to obtain a root shell

Crucially, the on-disk file is never modified. The corruption exists only in the kernel's page cache. Standard disk-based forensics (file integrity checkers, checksums) will not detect it. The modification disappears on reboot or if the kernel evicts the page under memory pressure.

The published exploit requires only standard Linux syscalls (socket, setsockopt, splice, sendmsg, recvmsg) and the authencesn algorithm which is available in default kernel configurations. No race conditions, no timing windows, no version-specific payloads are required.

Attack Characteristics

Comparison to Prior Linux Kernel LPEs

Copy Fail draws direct comparisons to two previous high-profile Linux kernel privilege escalation flaws:

Copy Fail is considered more reliable than Dirty Cow (race condition) and similarly impactful to Dirty Pipe, but affecting a broader kernel version range.

Discovery

On March 23, 2026, Taeyang Lee of Theori reported the vulnerability to the Linux kernel security team. The flaw was discovered using Theori's AI-assisted security analysis tool, Xint Code, which identified the dangerous in-place semantics introduced by commit 72548b093ee3 in 2017 — a near-decade-old optimization that had gone undetected through standard review.

Theori noted that the same research effort uncovered additional kernel security flaws, including at least one other privilege escalation issue, which remained under coordinated disclosure at the time of Copy Fail's public release.

Exploitation Context

A working public exploit was released on the same day as public disclosure (April 29, 2026), giving defenders essentially no window before reliable exploitation became possible by any threat actor.

• PoC: theori-io/copy-fail-CVE-2026-31431 — 732-byte Python script, no dependencies
• Tested platforms: Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, SUSE 16
• Container escape: Theori's Part 2 research covers exploitation from within containers
• Detection rule (Sysdig Falco): The Sysdig Threat Research Team published a Falco detection rule targeting the AF_ALG + splice() + setuid binary chain

CISA added Copy Fail to the KEV catalog on May 1, 2026 — two days after disclosure — confirming confirmed evidence of in-the-wild exploitation against federal or critical infrastructure targets.

Method of Detection

Check the Running Kernel Version

uname -r

Compare the output against the fixed versions in the Affected Versions table. Any kernel from 4.14 through the pre-fix versions is vulnerable. The algif_aead module loads on demand, so an unpatched kernel is at risk even if the module is not currently active.

Check Whether the Kernel Was Built With AEAD Support

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

Check Whether the Module Is Currently Loaded

Only applicable when CONFIG_CRYPTO_USER_API_AEAD=m (built-in modules do not appear in lsmod):

lsmod | grep algif_aead

Any output means the module is currently loaded and the attack surface is live. No output means it is not active at this moment but can still be demand-loaded unless explicitly blacklisted (see Workaround below).

Runtime Behavioral Detection (Falco)

The Sysdig Threat Research Team published a Falco rule targeting the exploit's syscall chain: socket(AF_ALG, SOCK_SEQPACKET) followed by splice() calls against a setuid binary. The rule is documented in Sysdig's Copy Fail analysis. Deploy it on any host where the module cannot be immediately blacklisted.

Critical limitation: Copy Fail corrupts only the kernel page cache — never the on-disk binary. File integrity monitoring tools (AIDE, Tripwire, auditd file watches, IMA/EVM) will not detect an active or completed exploit. The corrupted page-cache entry disappears on reboot or under memory pressure, leaving no persistent forensic trace on disk.

Remediation

Workaround

Prerequisite: First confirm that CONFIG_CRYPTO_USER_API_AEAD=m (module form) via the kernel config check above. If the result is =y (built-in), the module is compiled directly into the kernel and cannot be blacklisted — patching is the only option.

If a patched kernel package is not yet available from your distribution, apply both commands below — they serve different purposes and both are required:

# Prevent the module from loading on next boot and on any future modprobe call
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf

# Unload the module immediately if it is currently in memory
rmmod algif_aead 2>/dev/null

The first command writes a persistent blacklist entry — it survives reboots but does not affect a module that is already loaded. The second command evicts the module from the running kernel right now; the 2>/dev/null suppresses the harmless error if the module was not loaded to begin with.

Without root — confirm the blacklist entry is present by searching the modprobe config directories:

grep -r algif_aead /etc/modprobe.d/ /lib/modprobe.d/ 2>/dev/null

Expected output if the blacklist is in place:

/etc/modprobe.d/disable-algif-aead.conf:install algif_aead /bin/false

No output means the entry is absent. This confirms the rule exists in configuration but does not prove it is being enforced.

With root — definitive test: attempt to load the module and observe whether the block fires:

sudo modprobe algif_aead && echo "NOT BLOCKED" || echo "BLOCKED"

BLOCKED confirms the blacklist is effective — modprobe runs /bin/false instead of loading the module and exits non-zero. NOT BLOCKED means the blacklist is missing or not active. Note that lsmod | grep algif_aead is not a sufficient check: no output only means the module is not currently loaded, not that it cannot be loaded on demand. The modprobe blacklist entry persists across reboots. Note that this workaround blocks any legitimate use of AF_ALG AEAD sockets — in practice this affects only specialized cryptographic applications that explicitly use the kernel's userspace crypto API; standard TLS and disk encryption are unaffected.

For container environments where the module blacklist cannot be applied at the host level, apply a seccomp profile that blocks socket(AF_ALG, ...) calls from within container workloads.

Recommended Actions

1. Apply your distribution's patched kernel package — Ubuntu, RHEL, Amazon Linux, SUSE, AlmaLinux, Rocky Linux, Debian, and derivatives are all releasing updates. Check your package manager for kernel security updates.

2. Immediate interim mitigation — blacklist the vulnerable algif_aead module before a patched kernel is available:

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

   This prevents the module from loading. Verify with lsmod | grep algif_aead.

3. Prioritize multi-tenant environments — Kubernetes nodes, CI/CD runners, shared hosting systems, and any environment where untrusted users can run code are at highest risk. Exploit escalates any container or shell access to root on the host kernel.

4. Review container security posture — Assess whether workloads running as non-root in containers can still load AF_ALG sockets. Apply seccomp profiles that block socket(AF_ALG, ...) if the module blacklist cannot be applied immediately.

5. Monitor for additional Theori disclosures — Theori confirmed additional kernel vulnerabilities from the same research effort are under coordinated disclosure. Subscribe to kernel security mailing lists and your distribution's security advisories.

6. Verify the patch is applied — After updating, confirm the running kernel version matches or exceeds the fixed version for your LTS branch (see Affected Versions table above): uname -r.

7. Harden the kernel baseline — Copy Fail is one vulnerability. For a systematic approach to reducing the attack surface across the full class of Linux kernel local privilege escalation flaws, see Hardening the Linux Kernel: Defense in Depth Against Privilege Escalation, which covers the Kernel Self Protection Project (KSPP) baseline — including the compile-time and runtime controls most directly relevant to this vulnerability class.