Press enter or click to view image in full size
is a newly discovered Linux kernel flaw (April 2026) that lets any local user corrupt the in memory copy of any readable file (including setuid binaries) and gain root. It lives in the AF_ALG (user space crypto) subsystem. In 2017, a performance patch made AEAD cipher operations work “in place” (skipping an extra copy of data). Unfortunately this patch accidentally let a file’s page cache page slip into a writable buffer. An unprivileged user can then use the syscall splice() with an AF_ALG socket to write a few controlled bytes into that page. By targeting the right bytes in a setuid program, the attacker injects flags that run as root.
it affects all recent kernels 4.14+. Researchers at Theori disclosed a PoC using a 732 byte Python script to gain root on multiple Linux distributions. April 1, 2026, commit a664bf3d603d) simply reverts the optimization, restoring safety checks. Until patched, the advice is to disable the AF_ALG AEAD module or block AF_ALG sockets via seccomp.
When a file is opened or read, Linux stores a copy of its data in memory using something called the page cache so that future reads are faster. These cached pages can be shared by multiple processes, and even across containers. If a file is owned by root, a regular user can only read it and not modify it, and the same restriction applies to the cached version in memory. Even though the data is in RAM, a normal user should not be able to change it.
Linux provides a crypto interface called AF_ALG that lets user programs request encryption or authentication directly from the kernel through sockets. A process first creates a socket using AF_ALG and binds it to a specific cipher, such as authencesn with hmac and aes. It then uses setsockopt to configure things like the encryption key and mode. After that, it calls accept to obtain a crypto file descriptor. The process can then send plaintext and any associated data, and receive the resulting ciphertext along with the authentication tag
Behind the scenes AF_ALG uses scatterlists lists of memory pages that describe input and output buffers. Normally, the kernel would allocate a fresh output buffer and copy or encrypt into it. The 2017 patch changed that.
splice() and Pipe Buffers
The splice system call allows data to be moved between file descriptors entirely within the kernel, without copying it into user space. For example, using splice from a file descriptor to a pipe can move file data directly into the kernel’s pipe buffers. These pipe buffers include a field that can reference the same pages used in the file’s page cache. From there, another splice call can move those same pages from the pipe into an AF_ALG socket. In this way, splice can pass file-backed page cache data directly into the kernel’s crypto interface without creating a separate copy.
In Linux version 4.14, released in July 2017, a change was introduced in the file crypto/algif_aead.c to make AEAD operations run in place. The goal was to improve performance by avoiding extra memory copies. Instead of creating a separate output buffer for the encrypted data and authentication tag, the kernel reused the same buffer that held the input data. This meant the plaintext would be overwritten directly with the ciphertext, and the tag would be appended to it. For decryption, a small buffer was added to handle the tag.
Join Medium for free to get updates from this writer.
This approach reduced the need for additional memory allocation and copying, which could noticeably improve performance for large amounts of data. However, it relied on the assumption that the source and destination memory were effectively the same, which was not always true. In some cases, the code explicitly set the destination buffer to point to the same location as the source and used helper functions to chain additional memory for the tag. As a result, memory pages from one context, such as the page cache, could end up being reused as part of the output buffer, leading to unintended side effects.
The attacker starts by creating an AF_ALG AEAD socket using the algorithm authencesn with hmac sha256 and aes cbc. They call socket with AF_ALG, bind it to the chosen algorithm, set the encryption key using setsockopt, and then call accept to obtain a working crypto file descriptor.
Next, they choose a target file such as /usr/bin/su, which is owned by root and runs with elevated privileges. Using splice, they move data from the file descriptor directly into the crypto socket. This brings the file’s page cache pages into the operation. Because the kernel is using in place processing, those same pages are also treated as the output buffer.
The attacker then triggers the crypto operation using recvmsg. During processing, the algorithm writes a small amount of internal data beyond the expected output. Since the output buffer now points to the file’s cached pages, this write ends up modifying the page cache. By carefully controlling the input data, the attacker can influence the exact bytes written.
This process is repeated multiple times with different offsets. Each iteration allows a few bytes to be written into specific locations within the cached file. over several rounds, the attacker can gradually build up a meaningful modification in memory.
Finally, the attacker runs the target program. Because the system uses the modified page cache, the program executes with the injected changes. This effectively lets the attacker alter the behavior of a privileged binary in memory and gain elevated access without changing the file on disk
Imagine the attacker targets a program like /usr/bin/su, which runs with root privileges. They look for a specific location in the program’s code or data where changing just a few bytes can alter its behavior. For example, they might modify a check so it always passes, or redirect execution to run something else. By repeating the same technique multiple times, they can gradually place a small piece of shellcode in memory that ends up executing a shell. After that, running the program gives them a root shell.
Another approach (The expample is in one PoC) is to target something like /etc/passwd in memory. Instead of modifying the file on disk, the attacker changes how it appears in the page cache. For example, they can alter their user ID from 1000 to 0, which is root. The actual file on disk remains unchanged, so integrity checks still pass, but the system now treats that user as root while it is running.
This works because the “Copy Fail” issue allows the attacker to reliably write small chunks of controlled data into the page cache of a file.
No race condition or randomness is involved in this attack. It works on any vulnerable kernel. Because the page cache is shared across processes and even containers, it can also be used to escape from a container. At the same time, the file on disk is never modified, so common integrity monitoring tools like AIDE or Tripwire do not detect anything unusual. This is essentially a logic flaw in how buffers are handled, than a timing issue or a direct permission bypass.