Copy Fail Exploit Walkthrough - Linux Has A Serious Problem (CVE-2026-31431 )

Added: 2026-05-10

[00:00:00]Today we are diving into the infamous copy fail bug, a Linux privilege escalation bug. First, let me give you a quick sentence of how this bug works, which you can relay to a CISO or SLT manager who has somehow managed to fail upward into the role. Linux exposes a crypto API which trusts attacker controlled input and then lets that input influence where and what the kernel writes. This allows the user to change files it should never have right access to. For example, an attacker can abuse this to overwrite Etsy password related memory and elevate privileges from a normal user to root.

[00:00:46]For this video, I've created a modified version of rootsec dev's exploit which walks you through the vulnerabilities whilst showing you bits of the Linux memory we are changing. The first thing the exploit does is find the exact bite position of the current user's UID inside the xe password file on minishing. That's bte 1,386 where the UID 1 for my user RTR lives.

[00:01:17]Next, the exploit does an open read on the Etsy password file. This ensures it has been loaded into page cache. It's important to understand what page cache is. So, here's a quick explanation. The page cache is basically Linux holding file data in memory. So, it does not have to keep going back to disk every time the file is read. Only the kernel is supposed to manage and modify the page cache. As a normal user, we should have absolutely no business changing those bytes directly. However, copy fail chains three issues together, letting us influence the kernel into changing them for us. First, AFG gives userland a legitimate way to send data into the kernel crypto system through a socket. That part is by design. We want user space programs to be able to ask the kernel to encrypt and decrypt data rather than every application having to implement its own crypto from scratch. In the exploit, we first open the socket and then bind it to the ORF ink esn algorithm using HMAC char 256 and then using send message we provide the data we want the kernel crypto code to process. So send message contains a a c message socket message more. Aad consists of eight bytes containing two parts. The first four bytes are filler and the next four bytes are the value we actually want written. In our case those important four bytes are 30 30 30 30 which is the asky representation of 0 0.

[00:03:07]The seam message fls were set at the top of the code. Importantly, we set a sock length to eight which matches the size of our AAD. This is important and I will explain later. Message more tells the socket to stay open because we will be sending more data. Here comes our second issue. AFG was extended to support splice. And this is where things start getting interesting. Instead of copying normal userland data into the crypto socket, splice can pass the kernel a reference to filebacked memory. More specifically, it can point to data sitting in the page cache which we talked about earlier.

[00:03:51]AFG takes the data we just provided and represents it as a scatter gavl list because it is preparing that data to be passed into the kernel crypto system for decryption. A scattered gava list is basically a list of memory chunks.

[00:04:08]Instead of copying everything into one clean buffer, AFG can describe where the different pieces of data already live in memory and then hand the layout to the decryption code. However, because we used splice, we managed to place a reference to the page cacheed Etsy password file inside that list. Now we get to the third issue, the scratch right. The vulnerable crypto code uses something called OR incess.

[00:04:38]During decryption, it performs a small 4 by scratch right at a calculated position inside the scattergav list. So the important question is how do we make that position land exactly where we want? The crypto function needs to perform its four byte write from a into the scatter list below at the location as len plus crypten. Asocen is our aad so it equals 8 bytes. Crypten is the total length of the data we sent in minus the asoclin minus off tag size.

[00:05:15]ORF tag size is 32 bytes as that is what we spiced in earlier. So cryptoen becomes 40 - 8 - 32 which equals 0. That means the scratch right offset becomes aos len plus crypten.

[00:05:34]8 + 0 equals 8. And offset 8 is important because our aad is exactly 8 bytes long. So logical offset 8 is the first bite immediately after the AAD.

[00:05:50]And what did we put immediately after the AAD? The spliced page cache reference to Etsy password.

[00:05:59]So when Orink ESN performs its four byte scratch write, it lands at the start of the spliced page cache segment. The kernel thinks it is doing a tiny internal scratch write during decryption. But because we controlled the layout, that full bite right lands inside the cached Etsy password data.

[00:06:21]And because the four bytes we prepared earlier are 30 3030.

[00:06:26]The kernel ends up writing the ASKI string 0000 over our UID which gives us root access to the operating system.

[00:06:36]So, we've patched a page cache memory of Etsy password to tell the OS we are root. Until the system restarts or page cache does a refresh from disk, we will have root privileges. Here is a full animation from start to finish of the exploit. Go and check out that code on my GitHub if you want to get a feel for it yourself. It's the best way to learn.