New Linux Exploit Just Dropped (Before the Fix)

Added: 2026-05-12

[00:00:00]A second massive Linux vulnerability was just revealed and it's pretty bad. Just last week we had a pretty big one called copy fail, which we'll talk about briefly, but this new one is labeled dirty frag. And it says it's a universal LP that allows obtaining root privileges on all major distributions. Very similar to what we had seen with copy fail. For those of you unaware, a quick recap.

[00:00:22]Copy fail was also another critical Linux vulnerability discovered by Xint code, a AI powered research tool. and the bug had persisted in the kernel since 2017, affecting nearly every major Linux distribution. It was a logical flaw within the kernel's cryptographic subsystem, and it allowed for an unprivileged local user to escalate their privileges to admin or full root access. And it was particularly dangerous because it required no complex race conditions or kernel debugging features. it could be easily chained together by some basic what they call straight line logic in which a simple Python script could execute a local user's privileges and even escape containers. So we thought this was a big one and there was a fix and this particular one was already patched while we were learning about it. So we actually learned about it after it was found and basically shared with developers and kernel maintainers. But that's not the case with this one. Dirty Frag is serious because it also may let local users gain root or admin access on major Linux distributions as well. This is the second one in one week. Worst of all is that at the time of this recording, there are no official CVEes or even broad patches quite yet because the responsible disclosure schedule and embargo have been broken, which is definitely not good. We're going to get into all that and why this exactly happened. And it seems to be a lot of people who think this disclosure may be reckless as breaking an embargo can put users at a greater risk because attackers might start exploiting it immediately. Now, you do need local access in order to actually run this.

[00:01:55]Anyways, let's talk more about this vulnerability and how things came to be.

[00:01:59]So, the official information on it is actually in a repo called Dirty Frag and it is known as a universal Linux LP. LP just stands for local privilege escalation. That is a type of security flaw where someone who already has access to a machine as a normal user can gain higher privileges like a root or admin user. And in the abstract we actually see the different types of Linux distributions that are affected which is mostly every single Linux distribution. But how well in this case the bug class is very similar to what we saw with dirty pipe or copy fail because it is a deterministic logic bug that does not depend on a timing window. No race condition is required and the colonel does not panic when the exploit fails and the success rate is very high.

[00:02:41]And those of you wondering how it works, well, the background here is that again it's similar to dirty pipe or copy fail in which it can trick the Linux kernel into writing into a file that attacker is only supposed to read. The exploit abuses a performance feature called zero copy. Normally, when data moves through the kernel, Linux may avoid copying it for speed. Instead, it passes around references to the same memory page. So a normal user would open a protected file for example like user bins sue which is the same example that we used last time with readonly access. Then they use Linux networking and the splice function which makes the colonel treat a piece of that files cache memory as a part of a network packet. Then a vulnerable kernel path performs an in place crypto or decryption on that packet. The colonel then modifies that same memory buffer instead of copying it somewhere safe first. And because the packet buffer is secretly pointing to the files page cache, the kernel accidentally writes it into cache copy of a protected file, the attacker then repeats this in small chunks until they've cached a version of a program that's malicious and changes that program in memory. And when the program is ran, Linux can now execute the modified program because it's been modified in memory and the operating system has no idea of this. that gives the attacker root access. Pretty wild.

[00:04:01]Very similar to what we saw with copy fail. But one big reason why this is worse than copy fail. And if you don't want to fail to go over to Linux, then upgrade your Linux experience by checking out starlabs.systems/savvy3 where you can get an extra 3% off these amazing laptops. I personally use one as it's Linux first with no compromises. It comes pre-installed with Linux and has a wonderful premium workstation build all with core boot which is an open- source firmware ideal for people who care about open code privacy and performance.

[00:04:31]Anyways, you can get your new Linux workstation today at starlabs.system/savvy3.

[00:04:37]You can also use code savvy3 at the checkout for an extra 3% off. Let's talk about why dirty frag is worse than copy fail. And it's not because what this vulnerability can do. It's worse because there's really no real fix quite yet with copy fail. At least we had patch kernels and some patches to actually make. There was thousands of people working overnight in order to actually try and patch copy fail with dirty frag.

[00:05:03]Not only do we have a one line to run the exploit as it says do not use it on systems that you're not authorized to test. Well, we know people are going to try that, but it also has been tested to affect many Linux distributions already.

[00:05:17]The embargo was broken early, so the details of the exploit are now public before normal patch processes have actually finished and succeeded. So there's not even a CVE yet, making it harder for vendors to track. There's not even broad DRO patches yet, as we see some distributions scrambling to try and patch this in a very cluji way. So right now, most systems are going to be exposed until maintainers ship fixes and we saw what kind of chaos the copy fail created last week. The only immediate defense is a workaround like disabling the affected modules which may not be ideal for every system. Here's the disclosure timeline. As on April 30th, they submitted a detail about the vulnerability to the security at kernel.org proper channel. Same deal. On that same day, they submitted a patch for the vulnerability. They were able to reproduce it. And then on May 4th, a submitted shared frag approach patch was sent to the NetDev mailing list. The patch was then merged, submitted detailed information on the vulnerability exploit to the Linux DRO's mailing list on the beginning of the month on literally just today. And at the same token, detailed information about the exploit and vulnerability were published publicly by unrelated third party breaking the embargo and then after obtaining agreement from the distribution maintainers to fully disclose dirty frag, the entire document was published. So basically, they were forced to send out this vulnerability seemingly because someone broke the embargo. A third party unrelated potentially to this whole thing might have let it slip out. And from what I can tell, here is where the embargo was actually broken. Someone named Sik, also known as Dead Beef Network on GitHub, Sik said that they did not break the embargo from the inside. They claimed that they were not part of the Linux DRO's embargo and did not know that the planned May 12th disclosure date as a public kernel fix commit had landed. And once Sik ended up analyzing this public commit, they realized that it could be turned into a Linux privilege escalation bug. As Sik says here, I had no contact with anyone on the Linux distros embargo, no awareness on the May 12th disclosure date, and no access to Kim's writeup or PC. The work is endday weaponization from a public upstream commit which is standard practice once a security relevant fix lands in public tree flagging this so parallel nday work isn't characterized as a leak from inside the coordinated process. So breaking the embargo was actually just a mistake as sick claims they didn't actually leak anything from a private embargo. Instead they found a Linux kernel fix commit that was made public before the whole disclosure date.

[00:07:54]Someone noticed that the public fix looked like a security related issue and sik ended up looking at that public code change, figured out what the vulnerability was fixing, built an exploit from it and published it. So that that public exploit forced Dirty Frag to actually disclose earlier than planned. So I'm not sure that it was really an embargo issue more than someone found a security related issue and started reverse engineering the bug and created an exploit for it. Either way, that throws people up into a very big frenzy as there are no public patches at the moment. The only thing I've seen come through is from Alma Linux as they posted the dirty frag vulnerability fix is ready for testing.

[00:08:32]Alma now says that the patch kernels are currently in the testing repo because Red Hat has not shipped any patches yet themselves. So, you can actually install Alma Linux release testing and update the kernel from the Alma Linux testing repo. You got to enable the repo first and then reboot your machine and you will have the newly patched kernel and it's only a temporary workaround until the official kernel gets patched.

[00:08:56]There's also a temporary mitigation which is to stop kernel modules so they cannot be loaded and then unload them if they are already loaded. The three modules in question here are ESP4, ESP6 and RXRPC. These are all tied to the affected IPSec paths and can be removed by doing remove mod or rmod. Wild stuff happening over the last week as we see a second serious local privilege escalation bug arriving just one week after copy fail and hitting a very similar set of kernel vulnerabilities.

[00:09:30]Both bugs came down to the same basic idea and it's about how the kernel is handling shared memory allowing you to end up writing data that should have been copied first. And this timing makes this so much worse as the fact it's been released without a true patch in mind makes it much easier for exploiting.

[00:09:48]While the vulnerability is bad, the mistake on allowing people to understand the exploit before it was actually patched makes it worse. And this trend may be getting even worse as people are working with AI to get better at finding these types of deep memory handling bugs. Just like copy fail existed since 2017 by using a complex set of functions and instructions all at the kernel level. They were able to change up memory, change up what program code looks like in memory and then elevate privileges by using a program like Sue which elevates local user privileges.

[00:10:22]I'm sure there's going to be plenty of people working all night again disabling the modules that are affected. We'll see how things pan out. Regardless, you made it to the end of the video. You're a true fan. Make sure to subscribe below and smash that like button on the way back up. I'll catch you in the next one.

[00:10:35]Thanks for watching. Linux can be hard to understand, but I take the most commonly used terms, commands, and subjects in Linux, and I break them down into simple to read documents, including Linux terms, flashcards, a checklist, a cheat sheet, and a mind map. And if you're ready to level up your Linux experience and knowledge, go to savvyick.com now and get access to these sheets.