Copy Fail: The Linux Kernel Flaw That Hands Any Local User Root Access (CVE-2026-31431)

A single Python script. 732 bytes. No root. No race conditions. No special kernel features required. On any Linux system built since 2017, Ubuntu, RHEL, Amazon Linux, SUSE, that script gives you root.

That’s Copy Fail.

Key Takeaways

• CVE-2026-31431 (CVSS 7.8) is a local privilege escalation in the Linux kernel’s authencesn cryptographic module, introduced in August 2017.
• An unprivileged local user can write 4 controlled bytes into the page cache of any readable file, then execute modified binaries to gain root.
• The exploit is a 732-byte Python script that works identically on Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, and SUSE 16, no per-distro offsets.
• Patch: kernel commit a664bf3d603d. Interim: disable algif_aead via modprobe.

What Is Copy Fail and Why Does It Matter?

CVE-2026-31431, nicknamed Copy Fail, is a critical local privilege escalation flaw in the Linux kernel’s cryptographic subsystem, specifically the authencesn module, and it affects every major distribution running a kernel touched by a 2017 optimization commit (Xint Code, 2026). Unlike most LPEs that rely on race conditions, use-after-free chains, or kernel debugging features, this one is deterministic: it always works, every time, with no timing manipulation.

The vulnerability lets any unprivileged local user write four controlled bytes into the page cache of any readable file on the system. Four bytes is enough. Inject shellcode into a cached copy of /usr/bin/su, execute it, and you have root. The kernel never touches the disk. Integrity checking tools that scan disk files see nothing.

This is not a theoretical flaw. Working exploit code exists. It’s 732 bytes of standard Python.

CVE-2026-31431 allows an unprivileged local user to write four controlled bytes into the Linux kernel page cache of any readable file on the system, then execute the modified cached binary to gain root access. The exploit works without race conditions or kernel debugging features, is portable across major distributions, and completes via a 732-byte Python script (The Hacker News, 2026).

What Is the Root Cause of CVE-2026-31431?

Three independent kernel changes, introduced between 2011 and 2017, converged to create Copy Fail, and no single change is a vulnerability on its own (Xint Code, 2026). This is what made it go undetected for nearly a decade.

Change 1 (2011): The original authencesn implementation used destination buffers as temporary scratch space during authenticated encryption operations. This was an internal implementation detail, not a security boundary.

Change 2 (2015): The AF_ALG interface added splice() support, allowing userspace to pass page cache pages as inputs to kernel crypto operations. This was a legitimate performance optimization.

Change 3 (2017): A further optimization switched authencesn from out-of-place operations (separate source and destination) to in-place operations (same buffer for both). This is the commit that created the vulnerability.

The result: when authencesn processes an authenticated encryption request in-place, it writes beyond its legitimate output boundary into adjacent page cache pages. Userspace can craft a request that places a target file’s cached page in the write path. The kernel writes attacker-controlled bytes into it.

userspace trigger →
  AF_ALG socket → splice() → authencesn in-place op →
    out-of-bounds write → page cache corruption →
      /usr/bin/su cached page modified →
        shellcode execution → root

The algif_aead kernel module bridges the gap between the AF_ALG userspace interface and the authencesn template. It’s the exposure point, and it’s loaded by default on all affected distributions.

Which Systems Are Affected?

Any Linux system running a kernel that includes the 2017 in-place optimization is vulnerable (copy.fail, 2026). Confirmed affected distributions include:

Distribution	Versions
Ubuntu	24.04 LTS and prior releases with 2017+ kernels
Amazon Linux	2023
Red Hat Enterprise Linux	10.1
SUSE Linux Enterprise	16

The exploit script requires no modification between distributions. The same 732-byte Python runs on all of them without per-distro kernel offsets, a property the researchers explicitly tested and verified.

Not vulnerable: Systems running kernels patched with commit a664bf3d603d, or systems where algif_aead has been manually disabled.

Container environments: The shared page cache means container boundaries don’t help. A process inside a container can corrupt page cache pages accessible to processes outside it. This is a container escape vector.

How Does the Exploit Work?

The exploitation chain has four steps (The Hacker News, 2026):

1. Socket setup: Open an AF_ALG socket and bind it to specific cipher settings that will engage the vulnerable authencesn in-place path.

2. Payload construction: Build a shellcode payload that will be written into the target file’s page cache entry.

3. Write trigger: Use splice() to pass a reference to the target file’s page cache page (e.g., /usr/bin/su) into the crypto operation. The authencesn in-place write lands the shellcode into that page.

4. Execution: Call su (or whichever binary was targeted). The kernel executes the in-memory shellcode-injected version. The shellcode runs as the binary’s effective UID, root for SUID binaries.

The exploit produces no errors, no warnings, and leaves the disk untouched. Process accounting and file audit logs show a normal su execution. The page cache modification is entirely in-memory and is lost on reboot.

The Copy Fail exploit uses AF_ALG socket operations combined with splice() to trigger the authencesn kernel module’s out-of-bounds in-place write, corrupting the page cache copy of a target SUID binary. The entire operation completes in a single deterministic sequence with no race conditions, making detection and prevention via timing-based defenses ineffective (Xint Code, 2026).

Who Faces the Highest Risk?

Copy Fail requires a local unprivileged account, but that constraint covers a large attack surface in modern infrastructure (copy.fail, 2026):

High-risk environments:

• Multi-tenant Linux servers, any co-tenant user can escalate
• Kubernetes clusters, container escape is viable via shared page cache
• CI/CD runners, especially those executing code from pull requests or external contributors
• Cloud SaaS platforms, any system where users have shell access
• Developer machines, a compromised developer account (via phishing, for example) leads directly to root

Lower-risk environments:

• Single-user workstations where the local user already has sudo access
• Systems with mandatory access control (SELinux/AppArmor) in enforcing mode, though the extent of MAC policy coverage on the specific exploit path varies

The portability of the exploit, no per-distro modifications, no kernel offsets, means the same attack works against the broadest possible target pool. This is not a vulnerability that requires an attacker to tailor their tooling.

What Should You Do Right Now?

Priority 1, Patch. Apply kernel updates from your distribution that include mainline commit a664bf3d603d. All major affected distributions (Ubuntu, RHEL, Amazon Linux, SUSE) have released security advisories and patched kernels.

Priority 2, Interim mitigation (if patching is delayed):

# Prevent algif_aead from loading
echo "install algif_aead /bin/false" >> /etc/modprobe.d/disable-algif-aead.conf

# If already loaded, unload it
rmmod algif_aead

Priority 3, Assess exposure. Check whether any system in your environment:

• Has local user accounts beyond the system owner
• Is a multi-tenant or shared system
• Runs CI/CD pipelines with external code execution
• Is a Kubernetes node or container host

Priority 4, Verify patch status:

# Check if algif_aead is loaded (loaded = unpatched + vulnerable)
lsmod | grep algif_aead

# Check kernel version, verify against your distro's advisory
uname -r

What NOT to do: Do not treat container isolation as a mitigation. The page cache is shared across container boundaries on the host kernel. Patching the host kernel is the only reliable fix for containerized workloads.

Indicators of Exploitation

Copy Fail leaves minimal forensic trace, but these signals are worth monitoring:

Behavioral indicators:

• Unexpected SUID binary execution (especially su, sudo, newgrp) by non-interactive processes
• AF_ALG socket creation followed by splice() syscalls from non-cryptographic processes
• Processes gaining elevated privileges without corresponding sudo log entries
• In-memory-only file modifications detected via page cache inspection tools

Kernel auditing:

# Monitor AF_ALG socket usage via auditd
auditctl -a always,exit -F arch=b64 -S socket -F a0=38 -k alg_socket

The AF_ALG family number is 38 (AF_ALG = PF_ALG). This audit rule captures all AF_ALG socket creation events, which should be rare outside of specific cryptographic applications.

Frequently Asked Questions

Does this work over a network?

No. Copy Fail requires a local user account on the target system. It cannot be exploited remotely. The threat model is: attacker already has unprivileged local access (via phishing, stolen credentials, supply chain compromise, etc.) and uses this to escalate to root.

Will disabling containers or namespaces mitigate this?

No. The vulnerability is in the host kernel’s page cache, which is shared across all containers. The exploit works identically inside and outside containers. Patching the host kernel is the only reliable fix.

Does SELinux or AppArmor block the exploit?

It depends on the specific policy in place. Default enforcing SELinux policies on RHEL may limit some exploitation paths, but the vendors still issued patches and advisories, do not rely on MAC policies as a primary mitigation.

How was this found?

The vulnerability was discovered through AI-assisted research by Xint Code, with initial human research credited to Taeyang Lee at Xint. The disclosure timeline followed responsible disclosure practices, with affected distributions receiving advance notice before public disclosure.

Is there a working public exploit?

Yes. A 732-byte Python exploit exists and was demonstrated by the researchers. The exploit uses only Python standard library modules and requires no compilation.

References

• copy.fail, CVE-2026-31431 Official Disclosure
• The Hacker News, New Linux ‘Copy Fail’ Vulnerability (CVE-2026-31431)
• Xint Code, Copy Fail: CVE-2026-31431 Across Linux Distributions