What is CVE-2026-31431?
CVE-2026-31431, also known as Copy Fail, is a Linux kernel vulnerability in the algif_aead component of the kernel crypto subsystem. It is a local privilege escalation flaw, meaning an attacker generally needs some level of local code execution first, such as a shell, compromised service account, container workload, CI runner, or unprivileged user account.
The issue has been scored CVSS 3.1: 7.8 High by the CNA, [kernel.org](http://kernel.org), with the vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. NVD currently lists the CVE but has not yet provided its own NIST CVSS score.
The practical risk is serious: public reporting and technical write-ups describe the bug as allowing an unprivileged local user to corrupt the Linux page cache and potentially gain root privileges, especially by targeting setuid-root binaries.
The Short Explanation
Copy Fail is a bug in how the Linux kernel's crypto interface handled certain memory buffers.
A 2017 optimization tried to let algif_aead operate "in-place," meaning the same memory area could be treated as both input and output. That kind of optimization can be safe when the rules are simple and the memory ownership is clear. Here, it was not.
The kernel fix essentially backs out that complexity. The official CVE description says the kernel reverted algif_aead back to out-of-place operation because the source and destination come from different mappings, and there was no real benefit to handling them in-place.
In plain English: the kernel tried to be clever about avoiding a copy. That cleverness created a path where data could be written somewhere it should never have been written.
Why It Is Called "Copy Fail"
The name fits because the vulnerability is about a failed assumption around copying and memory references.
Linux has a page cache, which is an in-memory cache of file contents. When programs read files, Linux often serves the data from this cache instead of constantly going back to disk. Normally, an unprivileged user should not be able to modify the cached contents of protected files, especially files owned by root.
Copy Fail abuses a path involving:
- AF_ALG, the Linux userspace crypto socket interface
- algif_aead, the AEAD part of that crypto interface
- splice(), a system call that can move data between file descriptors efficiently
- page-cache-backed memory from readable files
The dangerous result is a controlled write into the page cache of a readable file. Some analyses describe this as a small, controlled four-byte write, but even a tiny write can be enough when applied to the right place in a privileged binary.
Why Page-Cache Corruption Matters
This is the part that makes Copy Fail especially interesting.
The attacker is not necessarily modifying the file on disk. Instead, they are modifying the in-memory cached copy that the kernel may later execute or serve. That means traditional file-integrity tools that compare disk checksums may not see anything wrong, because the actual file stored on disk has not changed.
Public reports note that this page-cache behavior can create a forensic blind spot for tools that focus on disk state rather than memory state.
That does not mean detection is impossible. It means defenders should not rely only on "the file hash still matches" as proof that nothing bad happened.
Who Is Affected?
The vulnerability affects Linux systems with vulnerable kernels containing the problematic algif_aead behavior. Multiple advisories describe the flaw as affecting many Linux distributions and kernels dating back to the 2017 change that introduced the in-place optimization.
Ubuntu states that the vulnerability affects Ubuntu releases before Resolute 26.04, and that fixes are available for affected Ubuntu releases.
Other vendors and distributions may differ in patch timing, kernel backports, module configuration, and mitigation guidance. The safest approach is to check your distribution's official CVE page or package advisory, not just the upstream kernel version number.
How Bad Is It?
For a single-user laptop, the risk depends on whether someone can already run code locally. For servers, shared systems, CI workers, container hosts, university shell servers, developer workstations, and multi-tenant environments, the risk is much higher.
The CVSS vector explains why:
- AV:L — the attacker needs local access
- AC:L — exploitation complexity is low
- PR:L — low privileges are enough
- UI:N — no user interaction is required
- C:H/I:H/A:H — confidentiality, integrity, and availability impact are all high
That combination makes it a classic local privilege escalation bug: not usually the first step in an attack, but very powerful after an attacker gets a foothold.
Why Containers Do Not Make This Disappear
Containers share the host kernel. That is the whole reason kernel vulnerabilities matter so much in containerized environments.
A container may feel isolated, but if an attacker can trigger a vulnerable kernel path from inside a container, the host kernel is still the component handling that request. Several advisories and analyses flag shared-kernel and container environments as especially important to patch quickly.
Strong container isolation, seccomp profiles, AppArmor, SELinux, and reduced capabilities can help, but they are not a substitute for a kernel fix.
What Should Defenders Do?
The main fix is simple: patch the kernel using your distribution's official security updates.
After patching, reboot into the fixed kernel. On Linux, installing the package is often not enough because the vulnerable kernel may remain running until the machine restarts or live patching is applied.
Practical response checklist:
- Identify systems running affected kernels
- Apply vendor kernel updates
- Reboot or confirm live patch coverage
- Prioritize shared hosts, container hosts, CI runners, bastion hosts, and systems with untrusted local users
- Review whether AF_ALG or vulnerable crypto modules are needed in your environment
- Use AppArmor, SELinux, and seccomp policies to reduce unnecessary access to kernel attack surfaces where possible
- Monitor for suspicious privilege escalation activity, unusual setuid binary execution, and unexpected root shells
Some temporary mitigations discussed publicly include restricting access to AF_ALG, disabling or blocking vulnerable modules where feasible, and tightening container sandbox policies. These should be treated as risk reduction, not permanent fixes.
The Bigger Lesson
Copy Fail is not just a Linux bug. It is a reminder about complexity.
The vulnerable behavior came from an optimization: avoiding extra copying by operating in-place. Optimizations like that are common in kernels because performance matters. But kernel code sits at the boundary between user-controlled inputs, privileged memory, filesystems, cryptography, and process execution. A small assumption error can become a root compromise.
The fix is telling: remove complexity, go back to out-of-place operation, and copy the associated data directly.
That is a useful engineering lesson. Sometimes the safest performance optimization is the one you delete.
Bottom Line
CVE-2026-31431, Copy Fail, is a high-severity Linux kernel local privilege escalation vulnerability in algif_aead. It abuses a flawed in-place crypto operation to create unintended writes into page-cache-backed memory. In real-world terms, that can let a low-privileged local attacker become root on vulnerable systems.
Patch your kernels, reboot into the fixed version, and give extra attention to shared Linux infrastructure where "local user" includes containers, build jobs, automation accounts, or partially compromised workloads.