Copy Fail: The Linux vulnerability that grants root access through page caching

Key points:
  • The attacker opens an AF_ALG socket and requests the authentication algorithm.
  • The attacker uses splice() to feed the socket with pages from the target file's cache (e.g., /usr/bin/su). These pages then become part of the output hash list (writable).
  • The attacker sends a message (sendmsg) with maliciously designed Associated Authenticated Data (AAD), where bytes 4-7 contain the data they wish to write (e.g., malicious code).
  • When decryption is triggered, authencesn takes those 4 bytes from the AAD and temporarily writes them to the end of the buffer. Due to in-place optimization, this end of the buffer points directly to the file cache page.
  • The cryptographic operation fails (the ciphertext is invalid), but the 4-byte write has already occurred and is never reversed.
  • The attacker repeats the process to inject their code. When /usr/bin/su is executed, the kernel loads the modified version from memory, executing the injected code with root privileges.
David Y. NaranjoUpdated on

4 minutes

copy fail

Linux security faces another challenge following the discovery of the vulnerability CVE-2026-31431, dubbed "Copy Fail" by the researchers at Xint Code. Far from being a theoretical flaw, this design problem It allows a local user without privileges to elevate their permissions and gain full access. as a superuser in a predictable and silent manner.

The researchers mention that this vulnerability has been successfully exploited in leading distributions such as Ubuntu, Amazon Linux, RHEL, and SUSE, confirming that any system running a kernel later than version 4.14 and keep up Enabling support for AF_ALG sockets is potentially vulnerable to this attack.

In-Place Operations and Page Cache Overflow

Regarding the ruling, it is mentioned that this It dates back to an optimization introduced in 2017 within the kernel's cryptographic API (AF_ALG). This modification I was looking to eliminate unnecessary buffering. executing authenticated encryption (AEAD) operations directly in the same memory space, which is known as "in-place" operations.

El A critical problem arises when combining this optimization with the splice() function, This method transfers data between file descriptors by transferring direct references to the kernel page cache instead of physically copying the data. When requesting decryption, the memory structure was configured so that the destination buffer, which should be a temporary space for the user, ended up being directly linked to the cache pages containing the system file data.

Authentication and writing outside the limits of memory

El The final trigger of the vulnerability lies in the anomalous behavior of the authencesn algorithm. Unlike other cryptographic routines that strictly respect the boundaries of their destination buffers, This specific algorithm uses the user's memory space as a temporary working area (scratch pad) to rearrange byte sequences during authentication tag calculation.

In this process, the algorithm writes four bytes beyond the established limit for the output region. Due to in-place optimization and the reference chain created by splice(),This seemingly harmless writing crosses the boundary of the user's memory and lands directly on the kernel cache page associated with the file being processed.

This chain of logical failures It grants the attacker the ability to arbitrarily overwrite four bytes in specific cache positions of pages for any file it can read. By sending a series of calculated requests, an attacker can inject malicious code in the in-memory version of critical executable files with the suid bit set, such as the user switcher tool.

Since all read operations first query the page cache, the next time the legitimate utility is invoked, The system will execute the injected code from memory, granting instant root privileges. without ever altering the physical file on the hard drive. Even more alarming, because container isolation shares the underlying host's page cache, this vulnerability serves as a direct gateway to escape virtualized environments like Kubernetes clusters and compromise the primary node.

Emergency patches and mitigation solutions

Given the seriousness of this ruling, the Maintenance teams have deployed emergency updates, where the definitive solution lies in Revert the in-place optimization within the algif_aead.c file, strictly separating the source and destination memory lists to prevent cached pages from ending up in writable paths.

These patches have already been integrated into kernels 6.18.22, 6.19.12, and 7.0, and are being backported to the long-term support branches. For administrators who cannot immediately restart or update their servers, it is recommended to disable the algif_aead kernel module if it was compiled externally, or to severely restrict the creation of AF_ALG sockets using security policies such as SELinux, a shield that, for example, has kept current Android devices safe from this threat.

Finally, if you are interested in learning more, you can find the details at the following link.