On April 29, researchers publicly disclosed a proof of concept (POC) named Copy Fail, a high-severity Linux local privilege escalation (LPE) vulnerability later tracked as CVE-2026-31431 (CVSS 7.8). It affects multiple major Linux distributions and lets a low-privileged local user corrupt page-cache-backed file content in memory. Pointed at a privileged executable such as /usr/bin/su, that corruption can escalate to root — while the original file on disk stays exactly as it was.
Soon after the POC went public, CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog.
Affected systems
- Kernel versions: 4.14 – 6.19.12
- Distributions: Ubuntu, Amazon Linux, Red Hat Enterprise Linux (RHEL), Debian, SUSE, AlmaLinux, Fedora, and Arch Linux.
The file on disk vs. the page cache
To understand Copy Fail, separate two ideas: the file on disk and the page cache.
Linux uses the page cache to keep file content in memory. It’s a performance win — the OS can read, map, or execute recently accessed files straight from memory instead of going back to disk every time.
Copy Fail does not modify protected files on disk. It abuses the interaction between splice(), AF_ALG, algif_aead, and authencesn to land a controlled 4-byte write into page-cache-backed memory. That becomes dangerous when the cached file is a privileged executable like /usr/bin/su, because Linux may execute the corrupted in-memory version while the on-disk file remains unchanged.
This risk is not limited to traditional Linux servers. In containerized environments, containers share the host kernel, and the page cache is managed at that shared kernel level. A vulnerable container host or Kubernetes node can expose more than one workload to the same issue, especially when untrusted code can reach the vulnerable crypto interface.
Public POC snippet demonstrating the Copy Fail exploitation flow.
How the chain works
AF_ALG
The chain begins with AF_ALG, a Linux socket interface that exposes the kernel crypto subsystem to user-space programs. Through it, a local process can request cryptographic operations from the kernel without implementing the crypto itself.
algif_aead
Behind AF_ALG, algif_aead handles AEAD (Authenticated Encryption with Associated Data) operations — combined encryption and integrity checking. It matters here because of a 2017 optimization that let it run “in-place.” Instead of keeping input and output buffers separate, the source and destination scatterlists could share the same physical memory pages to avoid copy overhead.
splice()
That memory handling breaks when chained with splice(). splice() transfers data between file descriptors and pipes without a normal user-space copy. Here, it passes file-backed page-cache pages by reference into the kernel crypto path — so the crypto operation can hold references to the same physical pages used by read(), mmap(), and execve() for that file.
authencesn
The final piece is authencesn, the AEAD crypto template where the critical scratch-write behavior lives. During decryption, authencesn uses the destination scatterlist as temporary scratch space and writes 4 bytes past the expected output boundary. In the vulnerable in-place path, that write can land inside page-cache-backed memory.
Now every link connects: splice() brings page-cache-backed file data into the operation, AF_ALG exposes the crypto interface, algif_aead allows the in-place AEAD layout, and authencesn performs the scratch write. The result is the core Copy Fail primitive: a controlled 4-byte write into the page cache.
The attacker controls the target file, the offset inside the cached content, and the 4-byte value written there. Four bytes sounds small, but it can flip a CPU instruction, a branch condition, or a security check. Repeated, the primitive can patch selected parts of a setuid-root binary in memory.
Copy Fail POC execution showing privilege escalation from a regular user to a root shell.
Why Copy Fail is worse than it looks
This is what makes Copy Fail stealthier than ordinary file tampering. A normal malicious change modifies the file on disk. Copy Fail changes the in-memory page cache while the on-disk file stays the same — so security tools that only compare disk hashes won’t see it.
It’s also more severe than earlier Linux LPE bugs like Dirty COW. Dirty COW relied on a race condition in copy-on-write behavior. Copy Fail is a straight-line logic flaw: no race window, no repeated timing attempts, no kernel-specific offsets, and no recompilation for the tested distributions.
How to mitigate Copy Fail
1. Patch your kernel
- Apply the kernel update from your distribution vendor for the affected range (4.14 – 6.19.12). Patches are rolling out across Ubuntu, RHEL, Debian, SUSE, Amazon Linux, AlmaLinux, Fedora, and Arch.
- A kernel update means a reboot. If you can’t reboot right away, use live patching where your distro supports it — Canonical Livepatch, Red Hat kpatch, SUSE Live Patching, or Oracle Ksplice.
- CISA’s KEV listing puts a hard remediation clock on federal agencies and is a strong prioritization signal for everyone else. Move this to the front of the queue.
2. Cut the chain
The exploit needs the kernel crypto interface to reach the in-place AEAD path. Take that path away and the primitive collapses.
- Disable the vulnerable module. If algif_aead is loaded and unused, unload it and blacklist it so it doesn’t come back on reboot:
rmmod algif_aead
echo "blacklist algif_aead" > /etc/modprobe.d/copyfail.conf
- If nothing on the host legitimately uses userspace crypto through AF_ALG, consider disabling the broader interface as well. Test first — libkcapi consumers and some crypto-offload setups depend on it.
3. Shrink the local attack surface
Copy Fail is a local privilege escalation: the attacker already needs a foothold as a low-privileged user. Make that foothold less useful.
- Block the AF_ALG socket family for untrusted processes with a seccomp filter that denies socket(AF_ALG, …).
- Use SELinux or AppArmor to restrict which domains can reach the crypto socket interface.
- Limit unprivileged user namespaces where you don’t need them — they’re a common stepping stone to kernel interfaces.
4. Harden containers and Kubernetes nodes
The page cache lives at the shared host kernel, so one vulnerable node can expose every workload running on it.
- Don’t co-locate untrusted or multi-tenant workloads on unpatched nodes.
- Apply a seccomp profile that blocks AF_ALG; the default runtime profiles don’t reliably cover it.
- Drop unnecessary capabilities and run containers as non-root.
- For genuinely untrusted code, use stronger isolation such as gVisor or Kata Containers so workloads don’t share the host kernel directly.
5. Adjust detection
Because Copy Fail never touches the file on disk, file-integrity monitoring that compares disk hashes is blind to it. Shift detection toward the exploit’s behavior instead.
- Alert on unusual AF_ALG socket creation and splice() activity from processes that have no business doing crypto.
- Watch for unexpected root shells spawned from low-privileged sessions.
- Lean on EDR and behavioral detection for privilege-escalation patterns rather than static file checks.
Bottom line: patch now, disable algif_aead if you can’t, and assume disk-based integrity checks won’t see it.
