CVE-2026-31431 Copy Fail: 732 Bytes to Linux Root

On April 29, 2026, Xint Code - an AI-assisted security research tool built by the offensive security firm Theori - publicly disclosed CVE-2026-31431, a high-severity local privilege escalation vulnerability in the Linux kernel that has been silently exploitable since 2017. Dubbed "Copy Fail," the vulnerability allows any unprivileged local user to gain full root access using a 732-byte Python script that works unmodified across Ubuntu, Amazon Linux, RHEL, SUSE, and virtually every mainstream Linux distribution shipped in the last nine years. CISA added it to the Known Exploited Vulnerability (KEV) catalog on May 1, 2026, and Microsoft Defender has published detection signatures confirming preliminary exploitation activity in the wild.

This is not a theoretical vulnerability. The proof-of-concept is public, deterministic, requires no race conditions, and works on the first attempt. For any organization running Linux in production - which is essentially every organization - this demands immediate attention.

What Is Copy Fail?

AF_ALG Logic Flaw

Copy Fail (CVE-2026-31431) is a logic flaw in the Linux kernel's AF_ALG cryptographic subsystem - specifically in the algif_aead module that handles Authenticated Encryption with Associated Data (AEAD) operations from userspace. The vulnerability allows an unprivileged user to perform a controlled 4-byte write into the kernel's page cache of any readable file on the system.

Page Cache Corruption Path

The page cache is the in-memory representation of files that the kernel maintains. When the kernel executes a binary, it reads from the page cache - not directly from disk. By corrupting the page cache copy of a setuid binary like /usr/bin/su, an attacker can inject shellcode that executes with root privileges. Critically, the on-disk file remains untouched, meaning traditional file integrity monitoring that checks disk-based checksums will miss the modification entirely.

CVSS Score

The CVSS score is 7.8 (High), reflecting the local attack vector combined with the complete impact to confidentiality, integrity, and availability upon successful exploitation.

Technical Root Cause: The AF_ALG + splice() Page Cache Corruption

AF_ALG Userspace Crypto Interface

Understanding why this vulnerability is so dangerous requires understanding how three independent kernel subsystems interact in a way that nobody anticipated for nearly a decade.

AF_ALG is a socket type (address family 38) that exposes the kernel's cryptographic API to unprivileged userspace processes. Any user can open an AF_ALG socket, bind to a crypto algorithm, and invoke encryption or decryption operations. No special privileges are required - this interface ships enabled by default on essentially every mainstream Linux distribution.

splice() and Page Cache References

The splice() system call transfers data between file descriptors and pipes without copying, passing page cache pages by reference. When a user splices a regular file into an AF_ALG socket, the socket's internal scatterlist holds direct references to the kernel's cached pages of that file - the same physical pages that back every read(), mmap(), and execve() call for that file system-wide.

The 2017 In-Place AEAD Optimization

In 2017, an optimization was introduced to perform AEAD operations in-place, setting req->src = req->dst so both point to the same scatterlist. This scatterlist now contained page cache pages from splice() chained into the writable destination via sg_chain(). The optimization was reasonable in isolation - but it placed read-only page cache pages into a writable scatterlist, separated from the legitimate write region by nothing more than an offset boundary.

authencesn Scratch Write Trigger

The trigger is the authencesn AEAD wrapper, used by IPsec for Extended Sequence Number support. During decryption, authencesn performs a 4-byte 'scratch write' of the seqno_lo field at offset dst[assoclen + cryptlen] - past the legitimate output boundary. In the in-place path, this write crosses from the output buffer into the chained page cache pages via scatterwalk_map_and_copy, which calls kmap_local_page and writes directly into the kernel's cached copy of the target file.

Attacker-Controlled Parameters

The attacker controls three critical parameters: which file (any file readable by the current user), which offset within that file (determined by splice offset, splice length, and assoclen), and which 4-byte value to write (bytes 4-7 of the AAD, constructed by the attacker in sendmsg). The HMAC computation then runs and fails (the ciphertext is fabricated), so recvmsg() returns EBADMSG - but the 4-byte page cache write has already landed and persists.

Why This Is Different From Previous Linux LPEs

Four Properties That Rarely Combine

Linux privilege escalation CVEs ship regularly. Most are race-dependent, narrowly version-specific, or both. Copy Fail breaks the pattern in four critical ways that almost never appear together.

Universal Portability

First, it is completely portable. The same unmodified 732-byte Python script roots Ubuntu, Amazon Linux, RHEL, and SUSE. No per-distro offsets, no version checks, no recompilation. The exploit uses only Python 3.10+ standard library modules (os, socket, zlib) - no compiled payloads, no dependencies.

Deterministic Reliability

Second, it is deterministic. Unlike Dirty Cow (CVE-2016-5195), which required winning a race condition in the VM subsystem's copy-on-write path and occasionally crashed the system, Copy Fail is straight-line code. It either fires or it doesn't, and it always fires. 100% reliability on a single attempt.

Stealth: No On-Disk Modification

Third, it is stealthy. The write bypasses the VFS path entirely. The corrupted page is never marked dirty by the kernel's writeback machinery - nothing hits disk. On page eviction or reboot, the cache reloads clean from the unmodified on-disk file. A forensic disk image shows the original file. Standard file integrity tools comparing on-disk checksums will miss it completely. Only tools that read via the page cache (like sha256sum during the active corruption window) or IMA appraisal in enforcing mode will detect it.

Cross-Container Page Cache Impact

Fourth - and this is the most concerning for cloud environments - the page cache is shared across containers and the host. Copy Fail is not just a local privilege escalation. It is a container escape primitive.

Kubernetes Container Escape: The Real Threat for Cloud Environments

From Kernel Bug to Infrastructure Risk

This is where Copy Fail transitions from a serious kernel vulnerability to a critical infrastructure risk. Because the page cache is shared across all processes on a Linux host - including across container boundaries - a compromised pod can use Copy Fail to escalate from an unprivileged container process to root on the underlying Kubernetes node.

Bypassing Default Container Isolation

Consider the standard Kubernetes threat model: containers provide process isolation, namespaces restrict visibility, seccomp profiles limit syscall access, and AppArmor/SELinux enforce mandatory access controls. Copy Fail bypasses default configurations of all of these because the page cache corruption happens inside the kernel, below the container isolation layer. The write uses standard kernel interfaces (AF_ALG sockets, splice()) that are not blocked by default seccomp profiles, and the corrupted page is immediately visible system-wide. Note that MAC mechanisms like SELinux and AppArmor *can* mitigate the exploit - but only when explicitly configured to deny access to the AF_ALG socket family, which is not the case in default policies.

Attack Chain: From Pod to Cluster

The attack chain is straightforward: an attacker compromises a pod (through a web application vulnerability, a supply chain attack on a container image, malicious code in a CI/CD pipeline, or any other initial access vector), runs the 732-byte Python script inside the pod as an unprivileged user, corrupts the page cache of a setuid binary on the host (containers share the host kernel and its page cache), and gains root on the Kubernetes node. From there, the attacker can access the kubelet credentials, read secrets from all pods on the node, pivot to other nodes, and potentially compromise the entire cluster.

Managed Kubernetes and Multi-Tenant Risk

For managed Kubernetes services (EKS, GKE, AKS), this is particularly concerning because customers typically do not control kernel patching timelines. The shared responsibility model means the cloud provider manages the node OS and kernel - but the vulnerability is exploitable from within any pod on the node. Organizations running multi-tenant Kubernetes clusters, CI/CD runners that execute untrusted code, or any workload where tenant-supplied containers run on shared nodes should treat this as a critical priority.

Microsoft's Container Escape Confirmation

Microsoft's analysis confirms this: 'Because the page cache is shared across containers and the host, the vulnerability also enables cross-container impacts and container escape scenarios.' Microsoft Defender for Cloud has published specific detection rules for exploitation attempts within container environments.

Affected Systems and Scope

Vulnerable Kernel Window

The scope of this vulnerability is unusually broad. Every Linux kernel built between 2017 (when the in-place AEAD optimization was introduced) and the patch (mainline commit a664bf3d603d) is affected. The AF_ALG crypto API ships enabled in the default kernel configuration of essentially every mainstream distribution.

Confirmed Distributions

According to Xint Code's disclosure, directly verified affected distributions include Ubuntu, Amazon Linux, RHEL, and SUSE running kernels within the affected window. Other distributions running affected kernels - Debian, Arch, Fedora, Rocky, Alma, Oracle - behave identically.

Exploitation Prerequisites

The prerequisites for exploitation are minimal: local code execution as a non-privileged user on a system running a vulnerable kernel with the AF_ALG crypto module enabled (which is the default). No network access, no kernel debugging features, no pre-installed tools beyond Python 3.10+.

Immediate Remediation Steps

Patch the Kernel

Patch the kernel. The upstream fix (commit a664bf3d603d) reverts the 2017 in-place AEAD optimization entirely, separating req->src and req->dst into distinct scatterlists so that page cache pages can never end up in the writable destination. Update your distribution's kernel packages to versions that include this fix. Most major distributions are shipping patched kernels now.

Disable algif_aead as Interim Mitigation

If you cannot patch immediately, disable the algif_aead module as an interim mitigation:

This blocks the AF_ALG AEAD socket creation that the exploit requires. For the vast majority of systems, disabling this module breaks nothing - dm-crypt/LUKS, kTLS, IPsec, OpenSSL (default builds), SSH, and all standard kernel crypto operations do not use AF_ALG. Only applications explicitly configured to use the afalg engine (rare) will be affected.

bash

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

Container Seccomp Defense-in-Depth

For container and Kubernetes environments, block AF_ALG socket creation via seccomp profiles regardless of patch status. This provides defense-in-depth even after the kernel is patched, because AF_ALG has historically been a source of kernel vulnerabilities and there is little legitimate reason for containerized workloads to access it.

bash

# Block AF_ALG socket creation via seccomp policies
# Add to your container seccomp profile:
{
  "names": ["socket"],
  "action": "SCMP_ACT_ERRNO",
  "args": [
    { "index": 0, "value": 38, "op": "SCMP_CMP_EQ" }
  ]
}

Deploy Detection

Deploy detection. Microsoft Defender has published signatures including Exploit:Linux/CopyFailExpDl.A, Exploit:Python/CopyFail.A, and Behavior:Linux/CVE-2026-31431. The rootsecdev/cve_2026_31431 repository on GitHub provides a non-destructive detector script (test_cve_2026_31431.py) that operates on a temporary sentinel file - never touching system binaries - and reports whether your kernel is vulnerable.

Audit Affected Systems

Audit your environment for any systems running kernels within the affected window. Prioritize multi-tenant hosts, CI/CD runners, Kubernetes nodes, and any system where untrusted code execution is possible. Treat any container RCE as potential host compromise until the kernel is patched.

Our Technical Opinion

Worse Than Dirty Pipe

Copy Fail is the most significant Linux privilege escalation vulnerability since Dirty Pipe - and in several respects, it is worse. The combination of universal portability (one script, every distro), deterministic reliability (no race conditions, single-shot success), stealth (no on-disk modification, no inotify trigger, no dirty page writeback), and cross-container impact (shared page cache enables container escape) makes this a best-case scenario for attackers and a worst-case scenario for defenders.

A 9-Year Window in the Kernel

The 9-year window between introduction and discovery is sobering. Three independent subsystems - AF_ALG userspace crypto, splice() page cache passthrough, and authencesn's scratch write behavior - each evolved independently over years, and the vulnerability exists only at their intersection. No single code review would have caught this unless the reviewer understood all three subsystems simultaneously. This is a structural problem with kernel development that goes beyond any individual CVE.

Kubernetes Isolation Assumptions Broken

We are particularly concerned about the Kubernetes implications. The container escape path is clean, reliable, and does not require any elevated capabilities. Most organizations' Kubernetes security postures assume that container isolation provides a meaningful boundary - Copy Fail demonstrates that this assumption is contingent on kernel integrity, and that a single unpatched node compromises the isolation model for every pod running on it.

AI-Assisted Vulnerability Discovery

The fact that this was discovered through AI-assisted vulnerability research is also noteworthy. Theori built Xint Code as an AI-powered tool to systematically analyze kernel attack surfaces. A human researcher identified the AF_ALG subsystem as an area of concern, and the AI tool scaled the analysis to identify the precise interaction between splice(), authencesn, and in-place AEAD that makes exploitation possible. As David Brumley of Bugcrowd has noted, this pattern - human intuition identifying attack surface, AI scaling the analysis - is likely to become the dominant vulnerability discovery methodology, which means the rate of high-severity kernel CVEs is likely to accelerate.

Recommendation: Patch Now

Our recommendation is unambiguous: patch now. If you cannot patch within 24 hours, disable algif_aead immediately and add AF_ALG to your seccomp deny lists for all containerized workloads. Do not wait for your next maintenance window. The public PoC, CISA KEV listing, and Microsoft's confirmation of preliminary exploitation activity mean the window between disclosure and widespread exploitation is measured in days, not weeks.