CopyFail Compromises The Last 9 Years Of Linux Distros

追加: 2026-05-07

[00:00:00]Currently, it is 2:00 a.m. I'm not a DRO maintainer. I'm just a guy ranting in his room about stupid things that are happening. Oh, what a terrible day it is to be a DRO maintainer. So, you know how we talk about the damage the XC back door could have done if it made its way into wide deployment. XZ was really bad.

[00:00:23]Thankfully, that didn't happen. Well, turns out we had something which arguably is worse because it actually did happen. It's actually in the real world. It's actually affecting basically every Linux system for the past 9 years. This exploit first appeared in the kernel back in 4.14 back in 2017 and affects everything up until a kernel version that came out sometime after March probably because this is a disclosure disaster as well. And we'll get to that, don't you worry. The initial write up for this was slop garbage. So much so that people didn't believe this was a real problem.

[00:01:22]And then when a real actual writeup came out, it sounded so insane that people still didn't think it was real. If all you care about is the immediate fix, here you go. Go and run this in your terminal. It disables the module which is affected and you'll be fine. Copy fail. 732 bytes to root on every major Linux distribution. CVE 2026 31431.

[00:02:00]This is really bad. Like really really bad. Here is a little video demo just to see what it can do.

[00:02:16]We now have root on every single one of these systems.

[00:02:23]That's all it took. This finding was AI system but began with an insight from theory researcher Tayang Lee who was studying how the Linux crypto subsystem that is cryptography not cryptocurrency interacts with page cashback data. This is a white hat hacker making use of this AI tooling. Black hats are doing the exact same thing. Welcome to the world of AI powered exploit discovery.

[00:02:49]Welcome to hell. This is an LPA, a local privilege escalation, meaning this is not done remotely. You need to be locally accessing the system. That might make it sound like this is not that big of a deal then. Well, combined with a very basic rce, a remote code execution, which are quite common, far more common than they should be, uh you can gain root access and thus control of basically any Linux system from the past 9 years. And especially when looking at those older unpatched machines, they're going to have known rce. So this is a realworld problem that can actually happen but it is not the first of its kind. There was dirty cow CV 20165195 which required winning a race condition in the VM subsystems copy on right path.

[00:03:44]It often needed multiple attempts and sometimes crashed the system. There was also dirty pipe CV 2022 0847. This was version specific and required precise pipe buffer manipulation. Copy fail is a straight line logic flaw. It triggers without races, retries, or crashprone timing windows.

[00:04:07]If a system can be exploited by this problem, if you can get the code on that system, you win. WHAT MAKES THAT much easier is this is portable. The same exact script works on every tested distribution and architecture including Auntu, Amazon, RE, Susa. No per DRO offsets, no recompilation, no version checks in the exploit. Now, some users have said they have not been able to execute it on their system. SE Linux does appear to be stopping the problem from happening. However, there's various other dros which are not using SE Linux.

[00:04:45]So it might be the proof of concept failing rather than the exploit itself failing. There might be a way to craft the exploit for some of those dros where it is not working currently. It is tiny.

[00:04:58]The entire exploit is a short Python script using only standard library modules OS socket and zib. This again is the proof of concept. There's a C version out there. There's a Go version out there. You don't need to have Python on the system. That's just how the testing version was written. Anything can do it. It is stealthy. The right bypass the ordinary VFS write path that is the virtual file system. The corrupted page is never marked dirty by the colonel's rightback machinery.

[00:05:27]Standard file integrity tools comparing on disk check sums will miss it because the ondisk file is unchanged. Only the in-memory page cache is corrupted. And the real big one, crosscontainer impact.

[00:05:43]The page cache is shared across all processes on a system including across container boundaries. Copy fail is not just a local privilege escalation. It is a container escape primitive and a Kubernetes node compromise vector.

[00:05:58]This is a big deal because a lot of the time, you know, things are, you know, containerized to keep them away from the rest of the system.

[00:06:09]Not this time. The system's affected. So the exporting question was found in the colonel's algif ae a module the root cause page cache pages in the writable scatter list. This is a relatively complicated exploit. I've read through it a number of times and I think I mostly understand it but I would recommend just if you don't follow along with me read it again yourself a few times. AFALG is a socket type that exposes the colonel's crypto subsystem to unprivileged user space.

[00:06:46]This is intentional. That's what it's supposed to do. A user can open a socket, bind to any AE authenticated encryption with associated data template and invoke encryption or decryption on arbitrary data. No privileges required.

[00:07:02]Again, this is intentional. That is what it is supposed to do. A core primitive underlying this bug is splice. It transfers data between folder descriptors and pipes without copying, passing page cache pages by reference.

[00:07:14]When a user splices a file into a pipe and then into an AFG socket, the socket input scatter holds direct references to the kernel's cache pages of that file.

[00:07:27]The pages are not duplicated. For AEA decryption, the input is a a associate authenticated data cipher text authentication tag. Inside algadcv message sets up the operation as in place, meaning the same scatteralist serves as both input and output for the crypto algorithm. The aad and cipher text data are bitecopied from the input scatter into the output buffer via memcopy SG list. This is a real copy.

[00:08:00]The page cache pages are only read, but the authentication tag, the last authorized bytes of the input scatter are not copied. So you copy this part here. This part stays the same. The kernel retains the scatter list entries for the tag and chains them onto the end of the output scatter using SG chain. So this isn't copied, but it references what is over here. The output scatter now has two regions. the recv message buffer containing copied aad and cipher text followed by the chained tag pages.

[00:08:33]Again, this is referencing the tag from the original input. Still referencing the original page cache pages of the file. The kernel sets w pointing to source equals w pointing to destination both pointing to the head of this combined chain. Both of these are pointing to the same place. This in place design is the root cause of the vulnerability. It places page cache pages in a writable scatteralist separated from the legitimate right region by nothing more than an offset boundary. The design assumes every AEA algorithm will confine its rights to the intended destination, but nothing in the API enforces this and nothing documented as a requirement. So if you stay within that offset boundary, things will be fine. But it's never stated that you need to stay within the boundary leading to one of them not following the imaginary spec. Hopefully all of that made sense, but I'm not 100% certain.

[00:09:36]Let me know down below. Now for the trigger. Authent scratch. Ornins ESN is an AEA wrapper used by IPSec for extended sequence number ESN support.

[00:09:48]IPSC uses 64-bit sequence numbers split into a high half, sect number high, bytes 0 to three of the AAD and a low half, SEC number low, bytes four to 7.

[00:09:59]The wire format carries only SEC number low, sect number high is implicit. For HMAC computation, this is hashbased message authentication code. Basically, a way to verify the data integrity and authenticity of the message. For this authent number high at the front of the hash input and sect number low appended at the end. And here is where the problem starts. It performs this rearrangement by using the caller's destination buffer as scratch base. Basically as modifiable memory that doesn't really matter. The first two calls shuffle the ESN bytes within the AAD region. A temporary modification that gets restored. The third call writes four bytes at offset asoclen plus cry len pass the ae aad tag. The algorithm is using memory it does not own as a scratchpad. Again as I said earlier it has to write within that offset boundary and that is exactly what it is not doing. The original bites at that position are permanently lost. This is a very important point for anyone who is going and testing this code on their actual machine. This will cause problems that you will have to fix. So if you want to test if you're affected, do it in a virtual machine or do it in a machine that you're happy to uh cause issues with SU not functioning. This function reads set number load back to reconstruct the AAD but never writes the original content back to destination at asoclen plus crypen. The position is treated as expendable scratch regardless of whether the operation succeeds or fails. This is also a very important part of it. And again, at least to the author's knowledge, nothing else does this. Everything else follows the imaginary undocumented spec. This doesn't. And now we have a problem. In the AFALG in place path, this right crosses from the output buffer into the chained page cache tag pages. Scatter walk map and copy walks past the RX buffer, maps the page cache page via KMAP local page and writes SEC number low directly into the kernel's cache copy of the file. The HMAC computation then runs and fails. The cipher text is fabricated. So wreck v message returns an error but the four byte controlled right sticks around. It persists.

[00:12:28]Crucially the attacker controls three things. Which file? Any file readable by the current user. Which offset the tag region corresponds to the last authorized bytes of the splice file data. By choosing the splice file offset, splice length and asoclen. The attacker determines exactly which four bytes when the files page cache are overwritten and which value the four byte overwrite value set number low comes from the bytes 4 to 7 of the AAD constructed by the attacker in send message. Now we'll get to uh the exact commit in a second. Firstly, the exploit. The proof of concept we have is targeting the user bin su a set UID root binary widely present on major Linux distributions. Now, it does not have to target that. There might be other vectors. So, even if this doesn't work on your DRO, it's still probably affected. Step one, socket setup. Open an AFG socket and bind to this. Set a key. Accept a request socket. No privileges required.

[00:13:36]AFLG is available to unprivileged users by default. Step two, construct the right. For each four byte chunk of the shell code payload, construct a send message plus splice pair. The send message provides the AAD bytes four to 7. Carry the four bytes to write sector number below. The splice provides the target files page cache pages as the cipher text and tag. The AEAD parameters asoclen splice offset and splice length are chosen so that destination asoclan plus crylen falls on the target offset within the user bin sus text section.

[00:14:12]Step three trigger the right recv triggers the decrypt operation inside orphans esn. The kernel reads the esn bytes from the aad write se number low at destination asoclanet plus cryland.

[00:14:25]The scatterw walk crosses from the output buffer into the chain page cache page. Four bytes are written to the kernel's cache copy of user bin su. The hmac is computed over the rearrange data and then fails. The kernel reads sec number load back to restore the aad, but the original bytes at the tag position are never restored. Recess returns an error. The page cache is corrupted. And then step four, execute. After all chunks are written, call exec CVE user bin SU. The kernel loads the binary from the page cache. The page cache version contains injected shell code because su is set UID root. The shell code runs as UID0 root. And there you go. You now have root access to the machine. This was publicly patched in this commit here about a month ago. Crypto alg a revert to operating out of place. this most reverts commit 72548B which is this one. I've lost my link.

[00:15:26]This one over here. This is from 2017.

[00:15:29]This is what introduced the problem.

[00:15:32]There is no place in operating in place in ALGIF AE since the source and destination come from different mappings. Get rid of all the complexity added for in place operation and just copy the AD directly. Note, this was done back in March. This is before public disclosure.

[00:15:53]This is all that is publicly said at the time. Following disclosure, the distress have released their notices. We have Debian, we have SUSA, Red Hat, KD Linux.

[00:16:04]Obviously, there is a GitHub notice. And amusing timing, the Iuntu website's down.

[00:16:11]Now, I don't think it's cuz of the exploit, but it's very funny timing. Now, notice on Debian the uh vulnerable here and then the fixed on the ones which are basically rolling.

[00:16:28]Why are they vulnerable? Okay, so in the write up, if we go to the coordinated disclosure, this was disclosed to the Linux kernel security team back in March. As we saw, it was patched back in March. Red Hat initially said they were going to defer the fix. Basically, not important. We'll get to it later. They have since changed that because they realized this was a big deal because, well, 8, 9, and 10 are all affected.

[00:17:02]That's a problem. This is published April 30th, 9:00 a.m. Berlin time. This is well after the exploit was already made public.

[00:17:15]Greg was doing kernel releases after that point. So this was disclosed to the kernel a month ago. You knew the problem was there and like the the most up-to-ate kernels have the patch but this not been backported to the older versions. You knew about the problem.

[00:17:36]We've known about it for a month.

[00:17:40]Why were these not released earlier? And better yet, why is there seemingly no coordination with the distros whatsoever? Rolling releases that have a modern kernel, they already have it patched. But things like Debian, they still have the vulnerability. Maybe that's changed as the time you're seeing this, but as I'm recording this, we're like 24 hours into this existing after a month of disclosure. And what the hell happened here? One thing worth noting is this does not seem to be generally applicable to Android, which is probably a good thing. Yes, it does site Claude, but I've seen others basically saying the same thing. So, it could certainly be worse. This is a mess. I'm going to go edit this video.

[00:18:34]Um, by the time you're seeing this, it's going to be about uh it's it's 3:00 a.m.

[00:18:39]right now. So, I'm going to edit this.

[00:18:40]It's probably going to go up about 4:00 a.m. or so. Then, I'm going to go to sleep, and we'll see when I wake up.

[00:18:50]I I don't like cutting a video this close. I really don't. So, this is a mess. I know other people are going to get videos out as well or may already have videos out. It's it's a mess. Just when your DRO releases a patch, install the patch. If they have a patch already, install the patch.

[00:19:11]What a mess. What a mess this is. If you have older machines, make sure those get patched as well because they might have RCE that can also be used with this.

[00:19:23]Yeah. Anyway, if you like the video, go like the video. Go subscribe as well.

[00:19:28]What a what a what a nightmare this is.

[00:19:31]So, yeah, if you really like the video and you want to become one of these amazing people over here that fund my coffee so I can make videos at 3:00 in the morning, um, that would be great. That would be wonderful. That's going to be it for me. I'm going to get rid of this now. So, I guess you guys will see this when it's edited.

[00:19:53]ain't playing your best. If it don't money, then I don't accept. If it don't involve money, then I don't accept something like this.