“Copy Fail” Linux kernel LPE and container escape
Published: April 30, 2026
Topics on this page:
Overview
We’ve been notified of this local privilege escalation vulnerability, in Linux kernel 4.14 (introduced in 2017), that affects most flavours of Linux. Recommendations are to patch or apply the mitigations to anything that can be, in particular, shared Linux hosts, Kubernetes nodes and container hosts as soon as possible.
Summary
Theori researcher Taeyang Lee, assisted by the Xint Code Research Team using AI-assisted analysis, has publicly disclosed a Linux kernel local privilege escalation vulnerability nicknamed “Copy Fail” (CVE-2026-31431). An unprivileged local user can write four controlled bytes into the page cache of any readable file on a Linux system and leverage that write to gain root. A 732-byte Python proof-of-concept (PoC) exploit has been released publicly on GitHub. The vulnerability has been present since Linux kernel 4.14 (introduced in 2017) and affects all major distributions via their unfixed kernel lines, including Ubuntu, RHEL, Amazon Linux, and SUSE. Kernel patches are available; immediate patching and module-level mitigation are strongly recommended.
Vulnerability details
CVE: CVE-2026-31431 (“Copy Fail”)
CVSS v3.1 Score: 7.8 (High) — Local Privilege Escalation
Disclosed: April 29, 2026
Reported to Linux Security Team: March 23, 2026
Upstream Patch Committed: April 1, 2026 (commit a664bf3d603d)
CVE Assigned: April 22, 2026
Exploit Status: A fully working public proof‑of‑concept was published on GitHub within 24 hours of disclosure and reliably achieves root across tested distros. [github.com]. As of today (April 30, 2026), Attacks in the wild have been reported by Exploit Intelligence. There are 91 identified PoC exploits in the wild.
The flaw is in the Linux kernel’s algif_aead code used by the AF_ALG cryptography socket interface. In 2017, a performance optimization made AEAD operations run “in place” by setting the source and destination buffers to the same memory. When a readable file is spliced into an AF_ALG socket, the kernel passes references to the file’s page cache pages rather than making copies. Because the source and destination buffers are shared, those normally read‑only page cache pages become writable.
The authencesn algorithm (used by IPsec for Extended Sequence Numbers) then uses the destination buffer as temporary scratch space and writes four bytes beyond the intended output boundary. That write lands directly in the page cache of the spliced file. The kernel does not mark the page dirty, so the file on disk is unchanged, and file‑integrity checks continue to pass.
Finally, the attacker executes a setuid binary whose in‑memory contents have been modified (for example, by altering cached /etc/passwd or /usr/bin/su data), resulting in a root shell. This bug emerged from the interaction of several reasonable design changes made over many years, which together created a powerful privilege‑escalation path that went unnoticed for nearly a decade.
Impact includes:
- Local privilege escalation (LPE) to root on any Linux host running a vulnerable kernel with the AF_ALG interface available
- Kubernetes container escape: because the page cache is shared across all processes on a host, including across container boundaries, a compromised container can corrupt setuid binaries visible to other containers and the host kernel
- Bypasses standard file integrity monitoring — on-disk files remain unchanged; only the in-memory page cache is corrupted
- Does not require a race condition, compiled code, kernel version offsets, or elevated capabilities
Impacted versions
All Linux kernels from version 4.14 onward are affected on systems where the AF_ALG socket interface and the authencesn / algif_aead module are available. The following distributions were confirmed vulnerable by the researchers:
| Distribution | Kernel version tested | Status |
|---|---|---|
| Ubuntu 24.04 LTS | 6.17.0-1007-aws | ❌ Vulnerable |
| Amazon Linux 2023 | 6.18.8-9.213.amzn2023 | ❌ Vulnerable |
| RHEL 14.3 | 6.12.0-124.45.1.e110_1 | ❌ Vulnerable |
| SUSE 16 | 6.12.0-160000.9-default | ❌ Vulnerable |
Vendor advisory pages:
Recommendations
- Patch immediately: If available, apply your distribution’s kernel update to address CVE-2026-31431, then reboot to load the new kernel.
- Harden containers and Kubernetes nodes: ensure host nodes are patched; restrict untrusted workloads from opening AF_ALG sockets (e.g., via seccomp, AppArmor, or SELinux policies); prefer minimal images that do not require AF_ALG socket access.
- Audit critical setuid binaries: check for unexpected behaviour in su, sudo, passwd, and other setuid binaries. Unexpected authentication successes or anomalous UID transitions may indicate exploitation.
- Limit local exposure: restrict interactive shell access on servers; review whether the authencesn IPsec module is required in your environment.
Mitigations
If immediate kernel patching and rebooting are not feasible, the attack surface can be eliminated by disabling the algif_aead kernel module. This prevents the AF_ALG AEAD interface from being loaded, blocking the exploit path entirely.
- Disable the algif_aead module (Linux)
Blacklist the module to prevent it from loading on next boot, then unload it from the running kernel:echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf rmmod algif_aead 2>/dev/null
- Verify the module is no longer loaded:
lsmod | grep algif_aead
A blank result confirms the module is unloaded.
Note: if any running application explicitly depends on AF_ALG AEAD operations, this may cause failures. Test in a non-production environment first. - Restrict AF_ALG socket access via seccomp or policy
In containerized environments, apply a seccomp profile or AppArmor/SELinux policy that denies socket(AF_ALG, …) calls for untrusted workloads. This limits container escape exposure even if the host kernel is not yet patched. - NSS / name service cache considerations
If exploited, the corruption targets the /etc/passwd page cache. If a name service caching daemon (nscd, sssd, or systemd-userdbd) is running, it may mask the corrupted in-memory state, causing the exploit to fail silently. This is not a reliable mitigation but may reduce success rates in some environments.
Detection & verification
Am I vulnerable?
A system is potentially vulnerable if it is running Linux kernel 4.14 or later and the algif_aead module is available. Check your running kernel version:
uname -r
Check whether the AF_ALG AEAD interface is loadable:
modinfo algif_aead
A public detection script is also available in the PoC repository. Running it as an unprivileged user will report whether preconditions are met without performing any writes:
python3 test_cve_2026_31431.py (SHA256 46F773601CF1D4A33E60F20D54C9A5427A20DD7E5DB6704A707B622358F6A8E8 )
Exit code 0 = not vulnerable (preconditions not met); exit code 2 = vulnerable; exit code 1 = test error.
References
Support
As always, please let us know if you have any questions or concerns or see unusual activity on your systems that you believe might be associated with this or any other vulnerability. Please send these communications to security.response@utoronto.ca.
