Copy Fail: The Nine-Year-Old Linux Bug That Gives Attackers Root Without Touching a Single File on Disk
A controlled 4-byte write into kernel memory is all it takes. The binary on disk is never modified, integrity checks stay quiet, and the attacker has root in seconds. CISA confirmed active exploitation, and every major Linux distribution shipped since 2017 is affected.
Most privilege escalation exploits leave evidence. A suspicious binary appears somewhere, a file gets modified, an integrity check fires, a log captures something unusual. Copy Fail does none of that. The attack corrupts a privileged binary entirely in memory, the version on disk stays clean, your file integrity monitoring never triggers, and the attacker walks away with root. It took nine years for this to surface: and now it has a public proof-of-concept, active exploitation confirmed by CISA, and working attack code in Python, Go, and Rust.
The vulnerability was disclosed on April 29, 2026 by researchers at Xint and Theori, who published a full technical write-up along with a 732-byte Python exploit that achieves root on unmodified enterprise distributions without recompilation or version-specific offsets. Their name for it, Copy Fail, captures the mechanism precisely: the kernel was supposed to copy data safely. It did not.
What Is Copy Fail and Where Did It Come From?
The flaw lives in the intersection of three Linux kernel features that were never designed to interact this way. The first is the AF_ALG socket interface, which exposes the kernel's cryptographic engine to unprivileged userspace processes. The second is the splice() system call, which can deliver pages from the filesystem's page cache directly into a crypto scatterlist, bypassing normal copy operations for efficiency. The third is an in-place AEAD optimization introduced in 2017, which instructed the kernel to reuse source memory as the destination buffer during certain authenticated encryption operations.
When a process chains these together, the authencesn algorithm (used for Extended Sequence Number rearrangement in IPsec) treats the caller's destination buffer as scratch space and writes four bytes beyond its intended output boundary. Because splice() fed the page cache pages of a real file into that scatterlist, those four bytes land inside the in-memory representation of that file. The attacker chooses the file. They choose a setuid binary, such as /usr/bin/su. They corrupt four bytes at a precise offset. The resulting in-memory binary, when executed, gives them root.
The on-disk file remains unchanged. The write avoids marking pages dirty for writeback. The exploit relies only on standard syscalls available in default kernel configurations with no additional modules required.Xint Research
Why This Is Harder to Detect Than a Typical Privilege Escalation
The standard defense against binary tampering is file integrity monitoring: tools like AIDE, Tripwire, or cloud-native equivalents that hash important system binaries and alert when they change. Copy Fail defeats this entirely. The on-disk copy of /usr/bin/su has the correct hash. The kernel's page cache, which is what actually executes when you run su, does not match it. That discrepancy exists only in memory and is invisible to any disk-based check.
There is also a container escape dimension. Linux containers share the host kernel's page cache. A process inside a container with no special privileges can use Copy Fail to corrupt page cache entries that are also visible to the host and to sibling containers. The kernel's memory, in this context, is not isolated by container boundaries. An attacker who starts inside a container arrives at root on the host node.
Unlike race-condition-based exploits, Copy Fail is deterministic. There is no timing window to miss, no retry loop required. The exploit runs, and it works. The public proof-of-concept is a 732-byte Python script using only standard library calls: os, socket, and zlib. Go and Rust ports have appeared in public repositories. The barrier to exploitation is as low as it gets.
Affected Distributions
The in-place AEAD optimization that introduced this vulnerability landed in the Linux kernel in early 2017. Any distribution shipping a kernel from that point forward is affected. That is not a narrow window.
| Distribution | Affected Versions | Patch Command |
|---|---|---|
| Ubuntu | All kernels from 2017+ | apt upgrade linux-image |
| RHEL | RHEL 10.1 and earlier | dnf update kernel |
| Amazon Linux | AL2023 and earlier | yum update kernel |
| SUSE / openSUSE | SLE 16, Tumbleweed | zypper update kernel |
| Debian | All kernels from 2017+ | apt upgrade linux-image |
| Fedora | All kernels from 2017+ | dnf update kernel |
The fixed upstream kernel versions are 6.18.22, 6.19.12, and 7.0. Most distribution packages will pull the appropriate backported fix through their standard update mechanism.
If You Cannot Patch Immediately
The algif_aead kernel module exposes the vulnerable interface. Blocking it from loading prevents the attack entirely without requiring a reboot. On any affected system where immediate kernel patching is not possible, run the following and persist the configuration across reboots:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf && rmmod algif_aead 2>/dev/null; true
This blocks algif_aead from loading. Applications that depend on this interface for AEAD operations via the kernel crypto userspace API will be affected, but the vast majority of standard server and development workloads have no dependency on it. Verify before applying in production environments where IPsec or specific cryptographic tooling is in active use.
What Your Team Needs to Do Right Now
- 1Check your kernel version on every Linux host: run
uname -rand compare against your distribution's patched kernel package. - 2Apply distribution kernel updates immediately across all servers, CI/CD build runners, and development machines. A reboot is required for the fix to take effect.
- 3If immediate patching is blocked: disable the
algif_aeadmodule using the modprobe configuration above. This is a stop-gap, not a substitute for patching. - 4In Kubernetes and containerized environments: kernel patches must be applied to the host node. Updating container images or application code does not address this. Every node in your cluster is independently exposed.
- 5Shared development environments and multi-tenant CI/CD runners are the highest-risk targets. Any unprivileged user or pipeline job on a shared host with access to standard syscalls can exploit this.
- 6After patching: drop the page cache to clear any in-memory corruption from the page cache of previously loaded binaries:
echo 3 > /proc/sys/vm/drop_caches. - 7Review audit logs for anomalous
AF_ALGsocket activity combined withsplice()calls from unprivileged processes: this is the behavioral signature of the exploit.
algif_aead as a temporary mitigation. Do not rely on file integrity monitoring to detect exploitation: Copy Fail specifically defeats disk-based integrity checks. The only reliable protection is a patched kernel.