CVE 2026 31431, commonly known as “Copy Fail”, is a high severity local privilege escalation vulnerability affecting the Linux kernel. The issue impacts kernels shipped by all major Linux distributions since 2017 and allows a local, unprivileged user to gain root level execution on the host system.

The vulnerability stems from a logic flaw within the Linux kernel cryptographic subsystem, specifically the algif_aead interface exposed via AF_ALG sockets. Under certain conditions, this flaw allows controlled modification of the kernel’s in‑memory page cache for read‑only files, including setuid root binaries. When such a modified binary is executed, the attacker can obtain elevated privileges.

Impact

An attacker with local code execution (for example, a standard user account, compromised service account, container breakout foothold, or malicious CI job) can:

  • Escalate privileges to root
  • Modify the in‑memory execution path of trusted binaries without altering files on disk
  • Evade detection mechanisms that rely solely on file integrity monitoring
  • Potentially escape containers on shared‑kernel platforms due to the global nature of the Linux page cache

Unlike earlier Linux privilege‑escalation flaws, Copy Fail:

  • Does not require race conditions
  • Does not depend on kernel‑specific memory offsets
  • Is deterministic and portable across distributions

 Affected Systems  

  • Linux kernels 4.14 and later that include the 2017 in‑place AEAD optimization in algif_aead
  • All major distributions shipping kernels built from 2017 until vendor patches are applied

 Recommendations  

  • Patch the kernel on any affected systems as the primary fix. This behavior is kernel-side; user-space controls alone are not sufficient.
  • Restrict AF_ALG usage for untrusted workloads using seccomp, SELinux, AppArmor, container policy, or hardening profiles if those workloads do not require kernel crypto sockets.

Proof‑of‑Concept Validation and Integrity360 Testing

Integrity360 conducted controlled dynamic analysis of publicly available Copy Fail proof‑of‑concept payloads to validate exploitability and assess operational risk.

Dynamic analysis through execution of the payloads revealed the exploit targets the Linux “Copy Fail” bug path by corrupting the page cache of a protected executable, specifically “su”, without opening that file for write. The payload opens the target read-only, repeatedly drives a kernel crypto interface through “AF_ALG”, moves target-backed data through splice, and then reports that the page cache has been mutated before executing the target.

This is not a normal file overwrite. The exploit abuses a kernel-side copy path so that the cached in-memory image of the executable is altered even though the file descriptor is read-only. The trace of dynamic analysis shows execution pivoting through “sh -c su”, followed by execution of “su”, which no longer behaves as the original “setuid” helper and instead falls through to “sh”. During execution we observed, “setgid(0)” and “setuid(0)” fail with “EPERM”, which is consistent with privilege elevation being suppressed under tracing; the exploit behavior is still visible because execution is redirected into a shell.

Technical Explanation

The exploit begins by opening “su” with “O_RDONLY” and announcing a payload of 1704 bytes (426 iterations). That number matters: the loop appears to patch the target in 4-byte chunks, with 426 x 4 = 1704. Each iteration creates a fresh “AF_ALG” socket, binds it to an “AEAD” crypto path, sets algorithm parameters with “setsockopt”, and sends a small, crafted control block with “sendmsg”.

The critical step is the pair of splice calls. First, bytes are spliced from the read-only target file descriptor into a pipe. Then they are spliced from the pipe into the accepted “AF_ALG” socket. That keeps the transfer inside kernel space and avoids a normal user-space write. After each attempt, “recvfrom” returns “EBADMSG”, which indicates the crypto operation failed from user space’s perspective, but the trace strongly shows the exploit is relying on a kernel-side side effect that survives that failure.

Near the end of the trace, the exploit performs the full 1704-byte transfer, closes the descriptors, prints page cache mutated; executing target, and immediately executes “sh -c su”. That leads to “execve("/usr/bin/su", ...)”, then failed “setgid(0)” and “setuid(0)”, and finally “execve("/bin/sh", ["sh"], [])”. That sequence indicates the cached image of “su” was modified so execution no longer follows the original program logic.

 

Most Critical Syscalls

  • openat:
    • Opens su read-only. This is important because it shows the exploit does not require write access to the target file.
  • socket(AF_ALG, SOCK_SEQPACKET, 0) followed by bind
    • These select the kernel crypto interface and the vulnerable processing path.
  • setsockopt:
    • Configures the AF_ALG operation so the crafted request can be accepted and processed.
  • sendmsg:
    • Supplies the per-iteration crafted control data and patch material.
  • pipe2:
    • Creates the in-kernel buffer path used to bridge file-backed pages into the crypto socket.
  • splice:
    • This is the core exploitation primitive in the trace. The exploit first splices from the target file into the pipe, then from the pipe into the AF_ALG socket. That is the syscall pair most directly tied to the actual cache corruption.
  • recvfrom:
    • Repeatedly returns EBADMSG. This is important because it shows the exploit succeeds despite an apparent operation failure, implying the corruption occurs before the error is surfaced.
  • execve:
    • Confirms the exploit outcome by immediately executing the tampered target path and then falling into sh.

 Kernel Versions Used in Integrity360 Testing 

 

 Successful exploitation  

  •  Linux 5.4.0‑122‑generic (x86_64)  

 Unsuccessful exploitation  

  •  Linux 7.0.0‑15‑generic (x86_64, patched kernel)  

Payload Reference

 https://github.com/tgies/copy-fail-c 

 

 If you are worried about any of the threats outlined in this bulletin or need help in determining what steps you should take to protect yourself from the most material threats facing your organisation, please contact your account manager, or alternatively get in touch to find out how you can protect your organisation. 

 

Contact Us