'Copy Fail': Linux Kernel Flaw Lets Any Local User Become Root

The CISA Automated Defender Program (ADP) enriched the CVE record on April 29, 2026, classifying the exploitation status as "poc" (proof-of-concept available), the Technical Impact as "total", and — critically — "Automatable: no", meaning the attack requires local access and cannot be fired blindly across the internet at scale. However, that limited comfort should not lull defenders into inaction: in the modern threat landscape, initial access via phishing, compromised credentials, or vulnerable internet-facing services is routine, and this vulnerability hands any attacker who achieves even a low-privileged foothold the keys to the entire kingdom.

CISA's classification of CWE-669 (Incorrect Resource Transfer Between Spheres) is the formal description of the flaw: the kernel incorrectly allows data to move between memory regions (file-backed page cache and cryptographic socket buffers) in a way that violates the intended access controls separating read-only and writable address spaces.

Understanding the Vulnerability

The Official Description

The Linux kernel CNA describes the vulnerability with characteristic understatement in the CVE record:

Translated from kernel-developer to English: a prior commit (72548b093ee3) changed the AEAD (Authenticated Encryption with Associated Data) socket interface to operate in-place — meaning it attempted to read and write data to the same memory region rather than copying between separate source and destination buffers. The problem is that in algif_aead, the source and destination fundamentally come from different memory mappings. When the kernel tries to perform an in-place cryptographic operation between a read-only file-backed page and an AF_ALG socket buffer, it fails to properly enforce the read-only nature of the source mapping. This is CWE-669 in action: data (and write permissions) are being transferred between memory spheres that should be strictly isolated from one another.

The affected source files, as listed in the official CVE record, are:

• crypto/af_alg.c — Core AF_ALG socket implementation
• crypto/algif_aead.c — AEAD-specific AF_ALG interface (primary vulnerable file)
• crypto/algif_skcipher.c — Symmetric cipher AF_ALG interface
• include/crypto/if_alg.h — AF_ALG interface header

What is AF_ALG?

AF_ALG (Address Family - ALG, also known as AF_ALG or socket family 38) is a Linux kernel interface that allows user-space applications to perform cryptographic operations — encryption, decryption, hashing, and authentication — using the kernel's built-in cryptographic accelerators. Think of it as a socket-based API to the kernel's crypto engine. It was introduced to give applications a standardized way to leverage hardware crypto acceleration without needing to reimplement algorithms in user space.

The aead (Authenticated Encryption with Associated Data) transformation type is used for algorithms like AES-GCM and similar constructs that simultaneously encrypt data and authenticate it. The specific algorithm invoked by the exploit, authencesn(hmac(sha256),cbc(aes)), is a composed AEAD construction combining HMAC-SHA256 authentication with AES-CBC encryption.

The Dirty Pipe Connection

This attack is conceptually reminiscent of CVE-2022-0847 (Dirty Pipe), one of the most impactful Linux kernel local privilege escalation vulnerabilities of recent years. Dirty Pipe also exploited the splice() system call and the kernel's pipe mechanism to overwrite read-only file-backed pages. "Copy Fail" follows a strikingly similar playbook: use splice() to bridge a read-only file descriptor into a kernel interface, then exploit a flaw in how that interface handles the underlying memory to write to the file's page cache. Security researchers tracking this vulnerability on oss-security have noted the family resemblance explicitly.

Step-by-Step Attack Chain

The attack proceeds in the following stages, as documented in Theori's public PoC:

1. Open a privileged target binary in read-only mode. The exploit targets /usr/bin/su — a setuid-root binary that, when executed by any user, runs with root privileges. Opening it read-only requires no special permissions.
2. Create an AF_ALG socket. The attacker creates a socket using protocol family 38 (AF_ALG) with type SOCK_SEQPACKET. This is entirely unprivileged — any user can create AF_ALG sockets by default on most Linux distributions.
3. Bind the socket to a specific AEAD cryptographic transformation. The socket is bound to the aead type with the algorithm authencesn(hmac(sha256),cbc(aes)). This primes the kernel's cryptographic engine for the specific data path the exploit needs to abuse.
4. Manipulate socket state with crafted setsockopt calls. Using setsockopt at level 279 (SOL_ALG) with specially crafted hexadecimal payloads, the attacker configures the cryptographic state of the socket in a specific way that sets up the in-place operation flaw.
5. Accept a connection and use sendmsg with crafted ancillary data. The attacker calls accept() on the socket (which is part of the AF_ALG accept-based API model) and uses sendmsg() with carefully constructed ancillary control message (cmsg) structures to further manipulate the kernel's internal data structures for the socket.
6. Create a pipe and invoke splice(). A standard Unix pipe is created. The os.splice() system call is used to move data from the read-only file descriptor (pointing to /usr/bin/su) into the pipe, and then from the pipe into the AF_ALG socket. This is the critical crossing point: the kernel's in-place operation code path is now handling page-cache-backed memory that it should not be allowed to modify.
7. Inject the malicious payload. A zlib-compressed replacement binary (a malicious substitute for /usr/bin/su that spawns a root shell) is decompressed and written in 4-byte chunks through the exploit primitive established in step 6. The write operations succeed despite the read-only permissions on the original file, overwriting the binary's contents in the kernel's page cache.
8. Execute the overwritten binary. The attacker calls os.system("su"). The kernel executes the now-malicious /usr/bin/su, which — because su is a setuid-root binary — runs as root and spawns an interactive root shell.

The Proof-of-Concept Code

Theori published a fully functional Python 3 exploit. The following is a faithful representation of the exploit's structure and logic as documented across multiple intelligence sources:

The above represents the exploit structure and logic as documented across multiple intelligence sources analyzing Theori's published PoC. The actual exploit at contains the complete, functional implementation including the full compressed binary payload, precise configuration bytes, and exact structures. The CVSS score of with vector reflects that the attack requires low-privileged local access (PR:L) but imposes low attack complexity (AC:L) and requires no user interaction (UI:N).

Who Is Affected

The official CVE record establishes a very wide impact window. The vulnerability was introduced with commit 72548b093ee3 and affects every kernel from version 4.14 onward until the patches landed.

Affected Kernel Version Range

Confirmed Affected Distributions (from Theori PoC testing)

Affected Source Files

The vulnerability is localized to the kernel's cryptographic user-space interface layer:

• crypto/af_alg.c — Core AF_ALG socket implementation
• crypto/algif_aead.c — Primary vulnerable component (AEAD-specific interface)
• crypto/algif_skcipher.c — Symmetric cipher interface (also patched)
• include/crypto/if_alg.h — AF_ALG interface header definitions

Scale of Exposure

The scope of this vulnerability is difficult to overstate. Linux kernel 4.14 was released in November 2017 — meaning this flaw has been present in the kernel for nearly nine years. Every Linux server, cloud instance, container host, embedded device, and workstation running a kernel in that range is potentially vulnerable if an attacker can obtain any form of local shell access. This includes:

• Cloud compute instances (AWS EC2, Google Cloud Compute Engine, Azure VMs) running Linux AMIs in the 4.14–6.18.21 range
• Container hosts where workloads run under shared kernel instances — a container escape combined with this flaw could yield host root
• Enterprise Linux servers running RHEL, SUSE, Ubuntu, and derivatives in the affected version ranges
• Development workstations and CI/CD build agents
• Multi-tenant systems such as shared hosting environments or HPC clusters where multiple users share a single kernel

The AF_ALG interface is enabled by default in virtually all mainstream Linux distributions and does not require any special kernel configuration to exploit.

Real-World Risk

Current Exploitation Status

As of April 30, 2026, no confirmed in-the-wild exploitation of CVE-2026-31431 has been reported by any threat intelligence source. However, the public availability of a fully functional, well-documented Python exploit changes the risk calculus dramatically. The gap between "no confirmed exploitation" and "actively exploited in the wild" can close within hours when a working exploit is freely available on GitHub.

CISA's SSVC assessment confirms the PoC status: Exploitation: poc. That rating is typically a precursor to the "active" exploitation classification, sometimes within days.

Attack Scenario: From Phishing to Root

Consider a realistic attack scenario for a cloud-hosted enterprise application:

1. An attacker sends a targeted phishing email to a developer. The developer clicks a link and their laptop credentials are harvested.
2. The attacker uses those credentials to authenticate to a VPN or bastion host, gaining SSH access to an internal development server.
3. The development server runs Ubuntu 24.04 LTS with kernel 6.17.0-1007-aws — confirmed vulnerable.
4. The attacker downloads the Theori PoC, runs python3 exploit.py, and has a root shell in under five seconds.
5. From root, the attacker installs a persistent backdoor, dumps credential stores, accesses secrets management systems, and pivots laterally across the network.

This is not a theoretical scenario. It is the standard post-exploitation playbook used by ransomware groups, nation-state actors, and cybercriminals alike. Local privilege escalation vulnerabilities are the critical second stage of nearly every serious intrusion.

Threat Actor Interest

No specific threat actor groups have been publicly linked to exploitation of CVE-2026-31431 at time of writing. However, vulnerabilities with these characteristics — high-impact local privilege escalation, publicly available working exploit, wide distribution version range — are highly attractive to:

• Ransomware operators who need root access to disable backups, encrypt storage volumes, and maximize damage
• Initial access brokers who sell elevated-privilege footholds on corporate networks
• Advanced Persistent Threat (APT) groups seeking persistent, stealthy root access on high-value targets
• Opportunistic attackers scanning for freshly patched CVEs to exploit before defenders have updated

The Setuid Binary Overwrite: Why It's Particularly Dangerous

The choice of /usr/bin/su as the target binary is not incidental. su (substitute user) is a setuid-root binary — its filesystem permissions are set so that it runs with root privileges regardless of which user executes it. By overwriting its contents in the kernel's page cache (without necessarily changing it on disk in a way that immediately triggers filesystem-level integrity checks), the attacker creates a trojan root shell that any subsequent execution of su will trigger.

This technique is particularly insidious because:

• It may not immediately modify the on-disk inode. Depending on kernel memory management behavior, the overwrite may be in the page cache only, potentially evading some file integrity monitoring solutions that only check on-disk checksums.
• The modification persists until the page is evicted from cache or the system reboots. On a busy server, that could be hours or days.
• Any user running su after the exploit is already triggered will execute the attacker's payload as root, potentially spreading the compromise to other users on the same system.

What You Should Do

Immediate Priority: Patch Your Kernel

The upstream kernel fix is available and the patched versions are clear. The single most important action is to update your kernel to a fixed version.

Fixed Kernel Versions

For distribution users, watch your vendor's security advisory channels for backported patches. As of April 30, 2026, distribution-specific patched packages are pending for the confirmed affected vendors (Ubuntu, RHEL, Amazon Linux, SUSE). Apply them as soon as they become available.

Distribution update commands (run as root or with sudo):

Immediate Workaround: Restrict or Disable AF_ALG

If patching is not immediately possible, consider restricting access to the AF_ALG kernel module. This is a partial mitigation — it specifically blocks the known exploit chain but does not fix the underlying flaw.

⚠️ Removing or blacklisting may break applications that rely on the kernel's user-space cryptographic API interface. Evaluate your workloads before applying this workaround in production. Test in a non-production environment first.

Alternatively, if your environment uses seccomp policies (common in containerized workloads), consider adding socket(AF_ALG) (socket family 38) to your seccomp deny lists to prevent unprivileged processes from opening AF_ALG sockets.

Detection: How to Know if You've Been Hit

Detecting active exploitation of "Copy Fail" requires monitoring at multiple layers. Here are actionable detection rules and indicators of compromise:

File Integrity Monitoring (FIM)

Deploy or verify FIM coverage on critical setuid binaries. The most immediate indicator of exploitation is an unexpected change to /usr/bin/su or similar setuid-root binaries:

Tools like AIDE, Tripwire, Osquery, or cloud-native FIM solutions (AWS GuardDuty file monitoring, Azure Defender for Servers) should be configured to alert on modifications to:

• /usr/bin/su
• /usr/bin/sudo
• /usr/bin/passwd
• /usr/sbin/mount
• Any other setuid-root binary

Note: Because the exploit may overwrite only the page cache and not immediately the on-disk inode, some FIM tools that only check inode metadata (mtime, ctime) without reading file contents may miss the attack. Ensure your FIM solution reads and checksums file contents, not just metadata.

Auditd Rules

Add the following auditd rules to detect the specific system call sequence used by the exploit:

Falco Rules (for containerized/cloud environments)

For environments using Falco (the CNCF runtime security tool):

Log Indicators to Hunt For

When reviewing existing logs for potential past exploitation:

• Auditd: Look for SYSCALL records with a0=38 (AF_ALG socket creation) followed closely in time by splice syscall records, originating from the same process, from non-root UIDs
• Auth logs (/var/log/auth.log, /var/log/secure): Unexpected root logins, especially from user accounts that have no legitimate reason to switch to root, or su sessions that begin without a prior password authentication event
• Process accounting / auditd EXECVE records: A Python interpreter process (python, python3) executing su or transitioning to a shell shortly after complex socket operations
• System call anomalies: Any process performing socket(AF_ALG) + setsockopt(level=279) + sendmsg + splice in rapid succession from a non-root UID is a near-certain indicator of either the exact exploit or a closely related variant

Broader Hardening Recommendations

1. Enforce least-privilege access. Limit which users have local shell access to sensitive systems. This vulnerability requires local shell access — if an attacker cannot log in, they cannot exploit it.
2. Implement Endpoint Detection and Response (EDR). Modern EDR solutions with behavioral detection capabilities should be configured with rules targeting the specific syscall sequence documented above (socket(AF_ALG) + splice on privileged binaries).
3. Audit setuid binaries regularly. Run periodic checks on all setuid-root binaries using content-based checksums. Consider a cron job or scheduled task that compares current SHA-256 hashes against a known-good baseline.
4. Container security: For containerized environments, verify that your container runtime (Docker, containerd, CRI-O) drops CAP_NET_ADMIN and uses a seccomp profile that restricts socket() calls to AF_ALG. Many default container seccomp profiles do not explicitly block AF_ALG socket creation.
5. Monitor distribution advisory channels now:

The Bigger Picture

"Copy Fail" is not just another Linux kernel CVE number to add to a list. It represents a recurring and troubling pattern in kernel security: complexity introduced through optimization creates exploitable confusion between memory access boundaries. The root commit that introduced this flaw (72548b093ee3) attempted to optimize the AEAD socket interface by switching it from out-of-place to in-place operations. In doing so, it created a crossing of memory "spheres" — a read-only file-backed page was suddenly being handled by code that could write to it. The fix, as described in the CVE record, is simply to revert that optimization: there was never a meaningful performance benefit for algif_aead in the first place, because the source and destination inherently come from different mappings.

Dirty Pipe's Heir

Security researchers will immediately recognize "Copy Fail" as the spiritual successor to Dirty Pipe (CVE-2022-0847), which also weaponized splice() and the kernel's pipe mechanism against read-only page-cache-backed files. Dirty Pipe was discovered by researcher Max Kellermann in February 2022 and triggered a massive industry-wide response. The fact that a similar class of vulnerability exists — exploiting the same fundamental data movement mechanisms — suggests that the kernel's splice/pipe/AF_ALG interaction surface warrants systematic re-review for similar confused deputy and memory sphere crossing issues.

The Anti-Bot Disclosure Friction Problem

There is a secondary story embedded in the intelligence gathering for this vulnerability that deserves mention. The canonical source for Linux kernel patch details — git.kernel.org — has deployed an Anubis (https://github.com/TecharoLLC/anubis) Proof-of-Work anti-bot protection system that blocks automated vulnerability intelligence systems from reading commit messages and patch diffs. This is a rational response to the documented, real problem of AI companies aggressively scraping open-source repositories. However, it creates a genuine friction point in the security ecosystem: automated vulnerability response platforms, SIEM enrichment feeds, and security research tools that rely on programmatic access to kernel.org patch data are now effectively blind to patch specifics until a human manually navigates the PoW challenge.

For CVE-2026-31431, this meant that security automation relying on kernel.org as a primary source had to fall back entirely to secondary sources — specifically, Theori's PoC repository — to understand the vulnerability. In this case, the PoC was sufficiently detailed to reconstruct the attack chain. But for vulnerabilities where the PoC is not public or is less descriptive, anti-scraping measures on canonical patch repositories could meaningfully delay the synthesis of defensive intelligence.

This is a problem the security community will need to navigate collectively: balancing the very real costs of AI scraping against the public security benefit of machine-readable vulnerability patch data.

What To Watch For

• Distribution vendor patches: Ubuntu, RHEL, Amazon Linux, and SUSE patches are pending as of April 30, 2026. Expect them within days to weeks. Treat their release as a hard deadline for kernel updates on all affected systems.
• In-the-wild exploitation reports: Given the public, working PoC, monitor threat intelligence feeds for reports of CVE-2026-31431 exploitation in ransomware intrusions or APT campaigns over the coming weeks.
• Variants and follow-on research: The disclosure of "Copy Fail" will almost certainly prompt security researchers to re-examine the broader splice() + AF_ALG interaction surface, the algif_skcipher.c interface (also patched in this fix), and related kernel crypto socket interfaces for similar CWE-669 flaws.
• CISA KEV addition: Watch for CVE-2026-31431 to appear on CISA's Known Exploited Vulnerabilities catalog if in-the-wild exploitation is confirmed. Federal agencies subject to BOD 22-01 would then face a mandatory remediation deadline.

The Linux kernel's security track record is strong, and the speed with which this fix landed in the stable tree before public disclosure is commendable. But a nine-year vulnerability window and a publicly available working exploit means that "Copy Fail" will require sustained, urgent attention from every organization running Linux infrastructure — which, in 2026, is essentially everyone.

Last updated: April 30, 2026. This article will be updated as vendor patches become available and if in-the-wild exploitation is confirmed.