How copy.fail achieves root from an unprivileged process
copy.fail is a local privilege escalation that targets the Linux kernel, not user-facing components like browsers or the clipboard. The exploit abuses the kernel crypto API — specifically AF_ALG sockets — in combination with splice() to write four bytes at a time directly into the page cache of a file the attacker does not own. The result is that an unprivileged process that can run code on a machine can promote itself to root. Importantly, the file on disk is never modified; on-disk integrity tools such as AIDE, Tripwire and checksum-based monitoring detect nothing.
Wide platform reach: works across major distributions with no tuning
The exploit, Theori reported, runs unmodified across Ubuntu, RHEL, Debian, SUSE, Amazon Linux, Fedora and most other distributions. It requires no race condition to win, and does not rely on per-distro memory offsets or fragile local conditions. That combination — a single PoC that operates broadly across mainstream kernels and distributions — is why Theori and others have described the issue as unusually serious.
Where shared infrastructure and modern workflows are exposed
Theori and subsequent write-ups frame the danger in concrete terms: “local” privilege escalation covers many contemporary shared-execution contexts. Every container on a shared Kubernetes node, every tenant on a shared hosting box, every CI/CD job that runs untrusted pull-request code, every WSL2 instance on a Windows laptop, and every containerised AI agent given shell access all share the host kernel with other workloads. In those environments, an attacker who can execute unprivileged code inside one context can use copy.fail to break the kernel boundary and obtain root over the whole machine.
Mitigations: what is and isn’t protecting you today
The default Kubernetes Pod Security Standards (Restricted) and the common RuntimeDefault seccomp profile do not block the syscall sequence used by the exploit; Theori notes that a custom seccomp profile is required to prevent the syscall from being used. In code-management terms the mainline kernel fix landed on 1 April 2026; distributions are rolling patched kernels now. The immediate operational imperative is straightforward and urgent: install the vendor kernel updates as they arrive and consider tailored seccomp restrictions where patching will be delayed.
What this means for technologists, Kubernetes operators, and CI/CD teams
- Technologists and security teams: expect an elevated incident-response burden. Because the exploit modifies the page cache rather than the on-disk file, checksum-based integrity controls will not flag post-exploitation changes. Teams should prioritize kernel patching and review default seccomp/containment profiles.
- Kubernetes operators and cloud providers: nodes hosting untrusted or multi-tenant workloads are at particular risk. The default Pod Security Standards (Restricted) and RuntimeDefault seccomp profiles do not prevent the syscall chain used by copy.fail; operators will need custom seccomp profiles or to expedite kernel upgrades across fleets.
- CI/CD and shared-hosting teams: any system that runs untrusted pull-request or tenant code should treat this as a high-severity isolation failure. Where immediate kernel patching is impractical, reduce risk by tightening execution policies and avoiding giving build agents or runners shell access that could reach the kernel attack surface.
Copy.fail is a reminder that a kernel-level flaw — especially one that leaves no trace on disk and works across distributions without local tailoring — changes the calculus for shared environments. The technical fix exists in mainline kernels as of 1 April, but the practical fix for many organizations is a race: roll the patched kernels through production, harden seccomp where possible, and assume that until host kernels are updated, any untrusted code running on shared machines represents an elevated risk.
Original story: https://www.schneier.com/blog/archives/2026/05/copy-fail-linux-vulnerability.html
