Copy.Fail: A Critical Linux Kernel Vulnerability Exposes Shared Infrastructure

Introduction

In late April 2026, security researchers at Theori disclosed a devastating Linux kernel vulnerability dubbed Copy.Fail. This is not your average bug – it's a local privilege escalation (LPE) that allows an unprivileged attacker to gain full root access on virtually any modern Linux system. The exploit works across all major distributions, including Ubuntu, RHEL, Debian, SUSE, Amazon Linux, and Fedora. Worse, it bypasses common security controls like Kubernetes Pod Security Standards (Restricted) and the default RuntimeDefault seccomp profile. The implications for shared infrastructure – containers, multi-tenant servers, and CI/CD environments – are severe.

What Is Copy.Fail?

Copy.Fail (the name is a play on the splice() syscall) is a local privilege escalation vulnerability in the Linux kernel. It is not a clipboard attack or a browser exploit, despite its catchy name. An attacker who already has arbitrary code execution capabilities as an unprivileged user can exploit Copy.Fail to become root. From there, they can read any file, install persistent backdoors, monitor all processes, and pivot to other systems on the network.

How Does the Exploit Work?

Abusing the Kernel Crypto API (AF_ALG)

The attack leverages the kernel's cryptographic API, accessed through AF_ALG sockets. This interface is designed for user-space programs to perform cryptographic operations. The exploit combines the AF_ALG socket with the splice() system call – a zero-copy mechanism for moving data between file descriptors. By using these in a carefully crafted sequence, the attacker can write four bytes at a time directly into the page cache of a file they do not own.

Writing to Page Cache Without Permissions

The page cache is a kernel data structure that stores cached copies of disk files. Normally, only the kernel can modify the page cache. Copy.Fail hijacks this mechanism, allowing an unprivileged user to overwrite arbitrary files by injecting data into their page cache entries. Crucially, the file on disk is never modified – only the in-memory cached version. This makes the attack invisible to integrity monitoring tools like AIDE, Tripwire, or any checksum-based file verification system.

Impact and Scope

The phrase “local privilege escalation” may sound technical, but its real-world impact is enormous. Consider these scenarios:

• Shared Kubernetes nodes: Every container on the same node shares the kernel. A compromised container can exploit Copy.Fail to break out and gain root on the host, then attack other pods.
• Multi-tenant hosting: A customer with shell access on a shared server can escalate to root and access other tenants' data.
• CI/CD pipelines: If a CI runner accepts untrusted code (e.g., from pull requests), a malicious job can escalate to root and compromise the build environment.
• WSL2 on Windows: A VM running under WSL2 shares the kernel with the host? (Actually WSL2 uses a separate kernel, but still relevant for Linux-only scenarios.)
• Containerized AI agents: Any sandbox that gives limited shell access to an AI model could be broken out of.

The exploit works without modification across all major distributions – no race conditions, no per-distro offsets. This universality makes it one of the most dangerous kernel LPEs in recent years.

Affected Systems and Containers

The copy.fail vulnerability affects default configurations on virtually every Linux distribution. Importantly, Kubernetes Pod Security Standards (Restricted) and the default RuntimeDefault seccomp profile do not block the syscall combination used (splice() and AF_ALG). Only a custom seccomp profile that explicitly denies these syscalls can mitigate the attack at the container runtime level.

Detection Challenges

Because Copy.Fail modifies the page cache rather than the underlying files on disk, traditional file integrity monitoring (FIM) tools cannot detect it. AIDE, Tripwire, Samhain, or any checksum-based solution will report no changes even after the exploit succeeds. Detection requires kernel-level monitoring or auditing of splice() and AF_ALG usage patterns. This makes the vulnerability particularly stealthy.

Mitigation and Patches

The mainline Linux kernel fix was committed on 1 April 2026. All major distributions are now rolling out patched kernels. The most effective mitigation is to update your kernel immediately. For container environments, consider deploying a custom seccomp profile that blocks splice() and AF_ALG for untrusted workloads – though this may break legitimate applications.

What You Should Do

1. Apply kernel updates from your distribution vendor as soon as they are available.
2. Review seccomp profiles for your container workloads. If your containers don't need splice() or crypto sockets, block them.
3. Audit for suspicious activity: Monitor logs for unusual use of splice() with AF_ALG sockets by low-privileged users.
4. Limit blast radius: Use Pod Security Standards (Baseline or Restricted) and ensure your cluster has proper network policies.

Conclusion

Copy.Fail is a stark reminder that the Linux kernel, despite its maturity, still harbors critical vulnerabilities. Its ability to bypass traditional monitoring and common security controls makes it a top priority for patch management. If you run any shared infrastructure – from Kubernetes clusters to multi-tenant servers – treat this as an immediate emergency. Patch now, and harden your container runtime profiles. The next exploit may not be so generously disclosed.