The Copy Fail Linux kernel flaw, tracked as CVE-2026-31431, is a local privilege escalation vulnerability that lets unprivileged users gain root access in seconds across every major Linux distribution released since 2017. CISA added it to its Known Exploited Vulnerabilities catalog after a public exploit dropped on April 29, 2026, and the flaw is now actively being weaponized in the wild. The vulnerability sits in the Linux kernel’s algif_aead module, part of the AF_ALG userspace crypto API, and exploits a logic flaw introduced during a 2017 optimization that nobody caught for nine years.
Key Takeaways
- Copy Fail Linux kernel flaw (CVE-2026-31431) enables root takeover from any local user in seconds, with CVSS score of 7.8.
- Affects all mainstream distros since 2017: Ubuntu 24.04 LTS, RHEL 10.1, Amazon Linux 2023, SUSE 16, CloudLinux, and others.
- Public exploit released April 29, 2026; upstream kernel patch committed April 1, 2026, but distro patches still rolling out.
- Works in containers by exploiting shared page cache across tenants, enabling cross-container privilege escalation.
- Requires only local access as non-privileged user; no race conditions, no kernel offsets, deterministic exploitation.
How the Copy Fail Linux kernel flaw Works
The vulnerability chains together three components: the AF_ALG asynchronous crypto socket interface, the splice() system call, and improper error handling in the kernel’s page cache. An attacker creates an AF_ALG socket using the authenc(hmac(sha256),cbc(aes)) algorithm, then uses splice() to feed controlled data into the crypto operation. When the HMAC verification fails, the kernel should discard the corrupted data—but instead leaves it in the page cache, allowing a 4-byte controlled write to an arbitrary location. The exploit is deterministic: no race conditions, no kernel address space layout randomization (ASLR) bypass needed, no guessing involved.
The attacker stages this primitive repeatedly, targeting setuid binaries like /usr/bin/su and writing shellcode into cached pages. Once the payload is in place, running su executes the patched binary and spawns a root shell. The entire attack takes seconds. Worse, because the page cache is shared across container boundaries, a compromised container tenant can escalate privileges across the entire host or sibling containers. This makes the Copy Fail Linux kernel flaw particularly dangerous in multi-tenant cloud environments where isolation is supposed to be guaranteed.
Which Linux Distributions Are Vulnerable
Every major Linux distribution remains vulnerable until patched. Ubuntu 24.04 LTS runs kernel 6.17.0, Amazon Linux 2023 ships kernel 6.18.8, RHEL 10.1 uses kernel 6.12.0, SUSE 16 and CloudLinux all carry the flawed code. The vulnerability exists in kernels since 2017, when the problematic optimization landed via commit 72548b093ee3, so older LTS releases are equally exposed. The upstream fix—commit a664bf3d603d—reverts that 2017 optimization and landed in the mainline kernel on April 1, 2026, but distros are patching at different speeds.
Ubuntu has disabled the algif_aead module entirely via a kmod package as a mitigation, while Red Hat offers configuration-level workarounds, but these are band-aids, not solutions. Distros that haven’t pushed kernel updates yet leave their users wide open. Unpatched systems will remain vulnerable indefinitely until administrators install the patched kernel and reboot.
Why CISA Flagged This as Actively Exploited
The public proof-of-concept exploit—a 732-byte Python script released by Theori on April 29, 2026—turned this from a theoretical flaw into a practical weapon. CISA’s decision to flag the Copy Fail Linux kernel flaw as actively exploited means evidence of real-world attacks already exists, and threat actors are using the PoC to compromise systems [title]. The speed of exploitation (seconds from local access to root) and the lack of any race condition or kernel knowledge requirement make this trivial to weaponize at scale. Any attacker with a foothold on a Linux box—via a web app vulnerability, SSH compromise, or container breakout—can immediately escalate to root.
Container environments are particularly at risk. A compromised application running in a container can exploit the Copy Fail Linux kernel flaw to escape its isolation boundary and compromise the host or neighboring tenants. This fundamentally breaks the security model of containerized deployments, where workload isolation is supposed to be enforced by the kernel itself.
Patching and Mitigation Timeline
The upstream kernel fix arrived April 1, 2026, but distro-specific patches are rolling out unevenly. Ubuntu pushed kernel updates with the fix; CloudLinux issued an update; Red Hat and SUSE are working through their release cycles. The lag between upstream fix and distro availability means many systems will remain vulnerable for weeks or months. System administrators cannot rely on automatic updates—they must actively apply patches and reboot to close the hole. For production servers, this means scheduling downtime; for containerized workloads, it means rebuilding images with patched kernels.
Temporary mitigations exist but are incomplete. Disabling the AF_ALG crypto module (as Ubuntu did) blocks the exploit vector but breaks legitimate applications that depend on it. Tightening file permissions or running with mandatory access control (MAC) policies like AppArmor or SELinux can raise the bar, but determined attackers will find workarounds. The only real fix is a patched kernel.
Why This Matters More Than Previous Linux Flaws
The Copy Fail Linux kernel flaw sits at the intersection of three dangerous properties: it affects every mainstream distro simultaneously, it requires zero privilege to trigger from an unprivileged account, and it works reliably in the most common deployment model (containers). Unlike some privilege escalation flaws that depend on obscure kernel configurations or require race condition wins, this one is a straight-line logic error. No attacker skill required. Compare this to other local privilege escalation vulnerabilities that demand kernel address leaks, precise timing, or specific hardware—Copy Fail is a gift to attackers.
The nine-year window between the vulnerable code’s introduction in 2017 and public disclosure in 2026 also signals a broader problem: security reviews of the crypto subsystem were not catching subtle logic errors in error handling. The kernel’s page cache interaction with socket operations created an unexpected side channel that nobody anticipated. This raises questions about what else might be lurking in similar code paths.
What Should Administrators Do Right Now
Apply the patched kernel immediately. Check your distro’s security advisories for the specific kernel version number. Ubuntu, RHEL, Amazon Linux, SUSE, and CloudLinux have all released updates. Reboot as soon as the maintenance window allows. For containerized environments, rebuild images with the patched kernel and redeploy workloads. If you cannot patch immediately, disable the AF_ALG crypto module as a temporary measure, though this may break legitimate applications. Monitor for signs of exploitation: unexpected root processes, suspicious /usr/bin/su activity, or privilege escalation attempts in audit logs.
Is the Copy Fail Linux kernel flaw exploitable remotely?
No. The Copy Fail Linux kernel flaw requires local access as a non-privileged user. An attacker must already have a foothold on the system—via a compromised web application, weak SSH credentials, or container breakout—before they can exploit it. This is why it pairs dangerously with other vulnerabilities: a remote code execution flaw in a web app becomes a full system compromise when chained with Copy Fail.
Which containers are at risk from this vulnerability?
All containers sharing a kernel with other tenants are at risk. Docker, Kubernetes, LXC, and any containerization technology that relies on the Linux kernel for isolation can be compromised. A malicious container can exploit Copy Fail to gain root on the host and escape to sibling containers. Kubernetes clusters running on vulnerable kernels should prioritize patching immediately.
Can disabling the AF_ALG module fully protect my system?
Disabling algif_aead blocks this specific exploit but is a workaround, not a fix. Applications depending on AF_ALG crypto operations will break. The proper solution is patching the kernel itself. If your applications do not use AF_ALG, disabling it provides temporary protection while you schedule a kernel update and reboot.
The Copy Fail Linux kernel flaw is a reminder that even mature, heavily audited code can harbor critical flaws for years. Every Linux administrator should treat this as urgent: check your distro’s security advisories, apply patches, and reboot. The window between public exploit release and full distro patch coverage is closing, and unpatched systems will not stay safe for long.
This article was written with AI assistance and editorially reviewed.
Source: Tom's Hardware
