The Linux kernel community is currently wrestling with one of the most significant Local Privilege Escalation (LPE) vulnerabilities in recent memory. Dubbed Copy Fail and tracked as CVE-2026-31431, this flaw allows a local user with zero special permissions to gain full root access in seconds.

If you’re getting a sense of déjà vu, it’s probably because this feels remarkably like the infamous Dirty Pipe CVE-2022-0847. However, Copy Fail is arguably more dangerous because it exploits a performance optimization that has been sitting quietly in the kernel since 2017, affecting nearly every major distribution in the wild.

The Technical Gory Details: How “Copy Fail” Works

At its heart, CVE-2026-31431 is a logic flaw within the algif_aead module, which is part of the AF_ALG userspace cryptographic API. The vulnerability was introduced when the kernel team implemented an “in-place” optimization to speed up crypto operations. In a standard cryptographic operation, you have a source buffer and a destination buffer. To save memory and cycles, the optimization allowed the kernel to use the same memory area for both (i.e., $req->src == req->dst$). The problem arises when this is combined with the splice() system call.

The Attack Chain

An attacker can chain three specific primitives to achieve escalation:

1. The Socket Setup: Open an AF_ALG socket for an Authenticated Encryption with Associated Data (AEAD) algorithm, such as authencesn(hmac(sha256), cbc(aes)).
2. The Splice Trap: Use splice() to move data from a read-only file (like /usr/bin/su or /etc/passwd) into the socket. Because splice() works by moving pages rather than copying data, the socket’s destination scatterlist now points directly to the kernel’s page cache—the in-memory cached version of that file.
3. The Overwrite: When the AEAD operation executes, it incorrectly performs a 4-byte scratch write of a sequence number (specifically the $seqno_lo$ field) into the destination.

Because the destination is the page cache, the kernel effectively writes those four bytes directly into the memory of a privileged binary. The attacker doesn’t need write permissions to the file on disk; they are only corrupting the version the kernel is currently holding in RAM.

Note: The exploit is entirely deterministic. It doesn’t rely on winning a race condition or spraying the heap. It is a surgical, four-byte strike that can turn a reject access instruction in a binary into a grant access one.

The Harm: Why “Copy Fail” is a Nightmare

The immediate risk is a total compromise of the host system. A 732-byte Python script is all it takes to trigger the vulnerability.

1. Root Escalation: An unprivileged user can corrupt the memory of /usr/bin/su to ignore password requirements or flip their own UID to 0 in the cached version of /etc/passwd.
2. Container Escape: Since the page cache is often shared between the host and its containers for performance, an attacker inside a restricted container can corrupt a host binary, facilitating a full container breakout.
3. Multi-tenant Compromise: In cloud environments or shared hosting, one compromised account can lead to the compromise of the entire physical node and every other tenant on it.

Affected Systems and Kernel Versions

The vulnerability is widespread because it stems from a commit (specifically 72548b093ee3) introduced in Linux Kernel 4.14 in July 2017.

• Ubuntu: 18.04, 20.04, 22.04, 24.04 LTS
• RHEL / Rocky / Alma: 8.x, 9.x, 10.1
• Debian: 10 (Buster), 11 (Bullseye), 12 (Bookworm)
• Amazon Linux: AL2, AL2023
• SUSE / openSUSE: SLE 15, SUSE 16

Vulnerable Kernel Range: 4.14 through 7.0-rc, all 6.18.x prior to 6.18.22, and 6.19.x prior to 6.19.12.

The Fix: Has it Been Released?

The fix involves a series of upstream commits that revert the unsafe in-place optimization and improve error handling during failed copy operations.

Upstream Fixes: Released in kernels 7.0, 6.19.12, and 6.18.22.

Distribution Status: Most major players (Ubuntu, Debian, Amazon) released patches between April 30 and May 2, 2026. However, some enterprise-grade distributions (like RHEL 8 and 9) may still have the fix in “Testing” or “Beta” repositories (e.g., cl7h_beta for CloudLinux).

How to Apply the Fix

For Ubuntu/Debian:

sudo apt update && sudo apt upgrade
sudo reboot

For RHEL/AlmaLinux/Rocky:

sudo dnf clean metadata && sudo dnf update kernel
sudo reboot

Detection: How to Tell if You’re Vulnerable or Infected

1. Identifying Vulnerability
   • The quickest way is to check your running kernel version:
   • uname -r
   • Compare your version against your vendor’s advisory. If you are running anything between 4.14 and 6.19.11, and haven’t updated in the last 72 hours, you are likely at risk.
2. The “Copy Fail” Detector
   • Security researchers at Theori and CloudLinux have released a non-destructive detector script. Unlike the exploit, it creates a temporary “sentinel” file and attempts to overwrite it rather than a system binary. If the sentinel file’s memory is modified, the system is confirmed vulnerable.
3. Runtime Detection (Falco/EDR)
   • If you cannot patch immediately, you can monitor for the “first step” of the exploit: the creation of an AF_ALG socket using the SOCK_SEQPACKET type. While some legitimate tools (like cryptsetup or systemd-cryptsetup) use these sockets, they are rare for standard user processes.

Mitigations (The “Band-Aid” Solutions)

If you are in a production environment where a reboot is impossible right now, you have a few options—but be careful, as some common advice is currently wrong.

1. The “Initcall” Blacklist (Effective): You can block the vulnerable module at boot by adding the following to your GRUB configuration:
   • initcall_blacklist=algif_aead_init
   • Note: This requires a reboot to take effect, which defeats the purpose for some, but it prevents the vulnerability from existing upon restart.
2. The Modprobe Trap (Ineffective on many systems):
   • Many guides suggest running rmmod algif_aead or blacklisting it in /etc/modprobe.d/. This often does not work. On many modern distributions (especially the RHEL family), algif_aead is built directly into the kernel (CONFIG_CRYPTO_USER_API_AEAD=y), meaning it cannot be removed or blocked via modprobe.
3. Seccomp/AppArmor:
   • Restrict the socket system call for unprivileged users, specifically blocking the AF_ALG protocol family if your applications don’t require it.

Final Thoughts

The disclosure of CVE-2026-31431 has been messy. Because the proof-of-concept was released before all enterprise distributions had stable patches ready, there was a 48-hour “free-for-all” window where systems were defenseless.

“Copy Fail” serves as a stark reminder that as we optimize the kernel for the speeds required by 2026 hardware, we often walk a tightrope between performance and security boundaries. If your Linux servers haven’t been touched in the last few days, now is the time to verify your kernel version.

Have you checked your uname -r today?