Linux bitten by second severe vulnerability in as many weeks

Production-version patches are coming online and should be installed pronto.

See full article...

 

[breze]

My biggest worry when I read these is cloud - not mine but my banks, etc.
Centos/Ubuntu/Debian on Google are pretty good, not so involved in azure/AWS. Thanks for the perspective, a nice Ars comment.

For your bank, not many people should have a user shell account on production systems, right?

 

[jrj]

So whatever happened to that 90 day rule? I thought people who found these sorts of exploits were supposed to tell the vendors/maintainers, and given them 90 days to get the patches out (and in this case, the distros) before disclosing vulnerabilities.

Is that not a thing anymore?

No. Linux security disclosure is an absolute mess.

The linux distro security coordination list allows for a maximum embargo period of two weeks.

The Linux kernel has its own disclosure rules, which is unlimited time to develop a fix under embargo. But once the fix is sent to Linus he will hold it for at most 1 week (it doesn't necessarily get held a all). The fix is then quietly published, and will only get assigned as CVE, etc after the fact. Notification is not supposed to be sent to the distro security coordination list until the fix is published in Linus's tree. There is nothing stopping the reporter from doing so, but doing can cause a lot of problems if Linus doesn't land the fix and pushes back for changes.

The problem with this model is everyone is watching Linus's tree for patches that could be security fixes and there is a race to reverse engineer an attack from the public fix. POCs do occasionally leak, but now with the progress in AI it is more common for the attack to be reverse engineered before the vulnerability details are published.

 

[jrj]

"The best response for anyone using Linux is to install patches immediately. While fixes likely require a reboot, protection from a threat as severe as Dirty Frag outweighs the cost of disruptions."

Honestly, as a distro maintainer (I'm the Fedora quality team lead), I would take a less urgent line than this for most folks. For single-user systems a root privilege escalation vuln is not really a huge deal. You are relatively unlikely to be vulnerable to it (because untrusted parties likely don't have shell access to your system), and root privilege separation is less of a big deal to you; the most likely user account to be compromised on your system is your own, and that's already where all your stuff is. If somebody compromises your user account they don't need a root privilege escalation exploit to do bad stuff to you.

This class of vuln is much worse news for anyone administering a system with multiple users. (Though I don't think it's been indicated that this one is usable for container or VM escape in common scenarios, which is a blessing).

Unfortunately it is a container escape

 

[jrj]

For your bank, not many people should have a user shell account on production systems, right?

One would hope but that may not be enough. You have to also consider if there are any other bugs on the system that would let an attack run shell code, no account needed, and you also have to worry about whether they are penny pinching using a cloud or production system that is using containers to isolate different services, and what those services allow.

 

[dreilide]

You, and the people upvoting you, should actually read the part of the post that says:

I did read that. It explains why certain containers have a lower risk profile than others, but it does not explain why exploiting a fully virtualized guest OS is a risk to the host while implying precisely that. It might, perhaps, be useful for chaining with a hypervisor exploit to escape the VM, but that's purely hypothetical and would be hypervisor dependent (e.g., qemu, VirtualBox, etc.)

 

[jrj]

This is not a facetious comment.

I thought open source software was not supposed to have these sort of bugs because it is open source and the code has already been checked and verified by many/any user?

I’ve seen many people post that ‘security by obscurity’ is not a thing. Is it also the case that being open source does also not guarantee security?

Many eyes only works when you have enough people with the right knowledge, looking and reviewing. The reality is open source struggles to get enough eyes on the code. Many projects are maintained by one or two people. Overall the quality of code in opensource is generally quite a bit better than closed source code, but it definitely still has bugs.

What security through obscurity buys you is time. If you don't have the code its harder find the flaws, harder but not impossible. If its harder fewer people are looking, fewer people looking means more time on average to find an exploit. However with the newer generation of AI, I am not sure if that this is even true anymore.

 

[Frodo Douchebaggins]

The rest of your post was some nice insight, thanks!

That "well over five minutes" is a masterful piece of understatement though

A blue whale displaces well over five gallons of water.

 

[AdamWill]

Dan, you got the timeline wrong.

On 2026-04-29, Hyunwoo Kim reported the vulnerability to the Linux kernel maintainers. On 2026-5-5, a kernel fix was published. On 2026-05-07, Kim notified Linux distro maintainers about the vulnerability, and a disclosure embargo was set for 5 days: no maintainer was supposed to publicly disclose details of the vulnerability for those 5 days, and once the 5 days were up, Kim would be free to disclose. On 2026-05-07, someone else independently analyzed the fix, figured out vulnerability, and not being aware of the embargo, published the details along with exploit code. So the embargo was broken: the secret was out. After that, Kim got permission from distro maintainers and publicly disclosed the details along with mitigation instructions.

There was no leak. It was not a zero-day. It's just another case of Linux distributions being too slow to take up kernel fixes.

Kernel changes are public the moment they're published. Even if a change isn't described as a security fix, people will figure out soon enough what the security implications are. Even if the good guys don't announce it, the bad guys will be exploiting it. The clock is ticking to get fixes deployed.

Why do you say distributions were "too slow"? As you said yourself, there was supposed to a five day embargo. Five days is a realistic (although still, honestly, aggressive) timeline for distributions to backport, test and prepare the fix for distribution. Two days is not going to happen.

"On 2026-05-07, someone else independently analyzed the fix, figured out vulnerability, and not being aware of the embargo, published the details along with exploit code."

It doesn't matter whether they were aware of an embargo or not - this is garbage practice. You don't just go around posting zero-day exploits.

 

[Amateur Nerd]

I can't actually remember Debian telling me to reboot after an update.

You might want to install needrestart though – unless you're using kexec a kernel update definitely requires a reboot.

Also, some updates affect so many daemons I restart anyway. On a headless system the OS start probably takes about as long as the EFI (even on older SSD), so the total downtime is low.

 

[YetAnotherAnonymousAppellation]

I'm in a good news/bad news situation. I planned to go full bore on Linux back when Win 10 "expired" on my W11-non-conforming laptop. The bad news is that I didn't manage to achieve that for many reasons that can largely be summed up as "didn't apply sufficient effort." The good news is that even though I'm running a potentially insecure W10 installation, I've dodged the (low caliber) bullet that is these 2 Linux vulnerabilities.

OK, it's a pretty lame excuse for a "win", but I'm going to take is as consolation for my failed plans.

 

[daslike]

I feel like these privilege escalation attacks are overblown. Any sophisticated attacker given shell access will likely be able to compromise a system anyways.

Systems install software. Software has bugs. There will almost always be angles to exploit.

Yes, this would allow less sophisticated attackers to do serious damage. But you generally don't have that many untrusted & unknown users. The barrier isn't how easy the exploit is to run. It's how many known users with access are willing to risk criminal penalties for hacking.

 

[Anton Longshot]

I own a very successful business using Mac's. This restarting/rebooting thing. What is that? According to the Linfets, Linux is totally secure!

In real life, NO operating system is secure. Remember the days when using the 'net was fun? And all we had to worry about was flashing banner ad's? What went wrong....

Errant apostrophy's.
I lie awake at night because of these monster's.
There should be law's against them with high fine's combined with public shaming.
For starter's!

I don't get it though.
I've never seen these very same people write spoon's or table's.
Why the f not?
Does ignoring their own rules make them feel like rebel's?

[/edit] Fun fact: these people don't just do this in the English language but also in Dutch

 

[jl22]

The reddit posts all had this title image. Peek use of the template.

 

[WonkoTheSaneUK]

Distros are already pushing out new kernels to mitigate Dirty Frag:-

7.0.6
6.18.29 LTS

Source:- https://www.phoronix.com/news/Linux-7.0.6-Released

 

[puelocesar]

I use Linux just so I can tell people in casual conversation that I use Linux.

Well, you could become vegan instead

 

[sjl]

I was assured that AI was going to bring us more secure and reliable software, not first to successfully attack existing security protection.

Oh well.

In fairness, to get to more secure and reliable software, you first need to find and fix as many vulnerabilities as possible. It’s not going to be the case that everything magically becomes secure overnight.

The situation is what it is. There’s no way to secure it without first breaking it like this. Even assuming that AI models can do what is claimed.

 

[JoHBE]

"Dirty Frag belongs to the same bug family as Dirty Pipe and Copy Fail, but it targets the frag member of the kernel’s struct sk_buff rather than pipe_buffer. The exploit uses splice() to plant a reference to a read-only page-cache page (for example, /etc/passwd or /usr/bin/su) into the frag slot of a sender-side skb. Receiver-side kernel code then performs in-place cryptographic operations on that frag, modifying the page cache in RAM. Every subsequent read of the file sees the corrupted version, even though the attacker only ever had read access."

That explains a lot! I suspected something like that /s

 

[alxx]

I was assured that AI was going to bring us more secure and reliable software, not first to successfully attack existing security protection.

Oh well.

I'm expecting a flood of cve's found using ai, then hopefully will drop off back to more normal levels.
Not just in the kernal but in lots of different packages not just language runtimes and apps and also in the Cloud platform and infrastructure level.

Then again ai doesn't always help with buggy app logic.

Some of the security tools with ai - prisma (soon or latest version) ,falcon , especially falcon are good at causing issues and quarantining things they shouldn't like virtual file system utilities in container platforms or builds in ci runners. Not fun when falcon is mandated to be installed on all platforms and instances.
Need very carefully generated exclusion policies and to whitelist platform components and utilities.

It was interesting to see how fast some vendors moved on copy fail especially some of the usually slower moving ones got patches with work arounds out in a couple of days. Bit slower on this one and mostly manual work arounds so far.

 

[shineEduc]

This is a concerning reminder of how critical Linux kernel security really is. Dirty Frag sounds especially dangerous because of its reliability and stealth. Timely patching and strong container security practices are becoming more important than ever.

 

[Charles Hunter]

You might want to install needrestart though – unless you're using kexec a kernel update definitely requires a reboot.

Also, some updates affect so many daemons I restart anyway. On a headless system the OS start probably takes about as long as the EFI (even on older SSD), so the total downtime is low.

Good tip. Thanks. Depending on what I see being updated, like you I will sometimes reboot anyway. The point was me having no memory of apt recommending/forcing reboots, unlike macOS which is one huge reboot cycle. Agree on reboot speed too. A Pi is ~30 secs, Debian guest on Proxmox running on an old Intel MacBook Pro with half a dozen Docker containers is ~20 seconds from hitting return until all containers are responding again.

And, as of today, Debian updates seem to have patches for CVEs associated with both Copy Fail and Dirty Frag. Go the maintainers!

 

[eduardopozo56]

Literally the only reason people tolerate Linux for. Now compromised.

Sure, M$lop never has vulnerabilities, right?

 

[ExhaustedTechConsumer]

"Dirty Frag belongs to the same bug family as Dirty Pipe and Copy Fail, but it targets the frag member of the kernel’s struct sk_buff rather than pipe_buffer. The exploit uses splice() to plant a reference to a read-only page-cache page (for example, /etc/passwd or /usr/bin/su) into the frag slot of a sender-side skb. Receiver-side kernel code then performs in-place cryptographic operations on that frag, modifying the page cache in RAM. Every subsequent read of the file sees the corrupted version, even though the attacker only ever had read access."

That explains a lot! I suspected something like that /s

You joke, and that particular paragraph meant little to me either but I dare say it was useful and interesting to a lot of people here.

Anyway, I feel like Dan's last couple of Linux vulnerability articles have been pretty good at explaining things and pointing to further information.

 

[adamsc]

What security through obscurity buys you is time. If you don't have the code its harder find the flaws, harder but not impossible. If its harder fewer people are looking, fewer people looking means more time on average to find an exploit. However with the newer generation of AI, I am not sure if that this is even true anymore.

I think this is going to be a rough year for open source but worse for the closed source slackers who’ve been relying on obscurity—not Microsoft, they’ve always had to assume reverse engineering in the current century, but there are a ton of apps which don’t easily lead to enough money for the higher-end groups to give them the same attention which Windows, iOS, Linux, Chrome, etc. receive.

The state-funded attackers are not going to start popping online storefronts or dentists’ scheduling apps but cryptocurrency really made a boom in the ransomware industry possible and there’s a scenario where those guys move downmarket if it becomes truly hard to find exploits in the most popular apps. They’d need to find more targets to make up for the smaller size but it’s plausible that LLMs will help them industrialize that.

 

[tlhIngan]

Unfortunately it is a container escape

Containers are nothing special. You've been using them for decades - you know it as "application isolation". Heck, you're using it now - your web browser runs as a separate process from anything else you have running - your email client, your work tools, other things. All a container is a special mode in Linux that says "you can have your own PIDs" which means you can run init again as PID 1, which can give you a unique userspace environment setup.

But as far as Linux itself is concerned, it's just running a bunch more processes - with a bit more accounting to keep them separated (namespaces). But if you can get access to root, you can do anything, including breaking out of your namespace.

The extra overhead of namespaces is just having a bunch of extra processes running in the background.

 

[adamsc]

Any sophisticated attacker given shell access will likely be able to compromise a system anyways.

There is a point here but it’s increasingly less true than it used to be: modern operating systems sandbox data (more on macOS than Linux but it’s getting better) and those controls are especially effective if the attacker only gets a way to run a single command but not, say, a full interactive session or arbitrary file operations.

 

[Diplodocidae_Guy]

Well, you could become vegan instead

I heard one once that went: "How do you know if someone is a pilot? Just wait, they will tell you." I've found it to be true in every case. I've never met a pilot who I didn't learn was a pilot within the first minute of meeting them. I suppose there could be a sampling error of incredibly bashful, secretive pilots running around, but somehow I doubt it.

 

[Tallawk]

arch btw?

I don't think your Steam Deck counts

 

[beheadedstraw]

I am a bit confused by the mentions of virtual machines here. The article almost makes it sound like this is a VM escape vulnerability, but I don't think that's the case based on other sources.

I was confused about this also, this is not a VM escape vulnerability, so why it's mentioned here is beyond me.

 

[beheadedstraw]

Containers are nothing special. You've been using them for decades - you know it as "application isolation". Heck, you're using it now - your web browser runs as a separate process from anything else you have running - your email client, your work tools, other things. All a container is a special mode in Linux that says "you can have your own PIDs" which means you can run init again as PID 1, which can give you a unique userspace environment setup.

But as far as Linux itself is concerned, it's just running a bunch more processes - with a bit more accounting to keep them separated (namespaces). But if you can get access to root, you can do anything, including breaking out of your namespace.

The extra overhead of namespaces is just having a bunch of extra processes running in the background.

Containers/Jails != App Isolation. App's still have access to your local hardware pointers, files, etc.

Also the only "extra processes" are the tools that manage the namespaces. Hardware resources are also separated via namespace and are presented to the extra namespace if configured as such. You can run as "root" in your own namespace. It's just logically isolated from actual root namespace/filesystem (chroot or in docker/containerd case pivot_root).

Mac OS is the only OS (besides appimages/snaps on Linux) that runs full "app isolation" using a form of BSD Jails.

 

[KenM]

arch btw?

Of course. (Well, a fork - Manjaro)

 

[Rivr]

Perfectly normal thing to happen, if you ask me. Such incredibly complex software constructs as operating systems are bound to have tons of weak points. The question is not how many there are, but how their revelation and fixing are being handled.

 

[momurda]

I use Linux just so I can tell people in casual conversation that I use Linux.

"What a guy!"

 

[hansdegoede]

You, and the people upvoting you, should actually read the part of the post that says:

Dan, I don't understand why you are doubling down on this. To me the article clearly suggests that VMs are more vulnerable then containers, where as this does allow container escapes and does not allow VM escapes.

A best interpretation of this is that the article is at least written in a confusing way. Please fix the article instead of doubling down.

Especially the “However, the risk remains significant for virtual machines" quote steers readers in completely the wrong direction. These exploits are a problem for machines with multi-user setups and using a single VM for a multiple users is a very uncommon setup.

Using VMs for isolation actually helps protect against these exploits where as containers are still vulnerable, currently the article basically suggests that this is the other way around.

 

[DarthSlack]

I'm in a good news/bad news situation. I planned to go full bore on Linux back when Win 10 "expired" on my W11-non-conforming laptop. The bad news is that I didn't manage to achieve that for many reasons that can largely be summed up as "didn't apply sufficient effort." The good news is that even though I'm running a potentially insecure W10 installation, I've dodged the (low caliber) bullet that is these 2 Linux vulnerabilities.

OK, it's a pretty lame excuse for a "win", but I'm going to take is as consolation for my failed plans.

"There's multiple holes in the bottom of my boat, but at least it's not THOSE two holes."

 

[Castellum Excors]

I was assured that AI was going to bring us more secure and reliable software, not first to successfully attack existing security protection.

Oh well.

AI will bring us more secure and reliable software. And then AI will attack it, then AI will patch it... and then AI will attack it, yet again. Whenever you build a better mousetrap evolution breeds a better mouse. It's the same as AV vs Malware as is. You built a better AV, along comes better, usually socially engineered, malware.

 

[obarthelemy]

You mean don’t enjoy 3 or more nested reboots during Windows patches? I always assume it’s the cold revenge for not having to reboot after every app install anymore.

Back when I worked at Novell, we always joked about the egregious number of restarts installing and running Windows Server required. This was sooooo bad....WServer is such a joke... Certainly it couldn't succee... oh, wait.

 

[gosand]

I use Linux just so I can tell people in casual conversation that I use Linux.

I think I'm doing it wrong, I've been using it since 1998 and keep forgetting to mention it to people in casual conversation.

 

[GreyAreaUK]

Back when I worked at Novell, we always joked about the egregious number of restarts installing and running Windows Server required. This was sooooo bad....WServer is such a joke... Certainly it couldn't succee... oh, wait.

I still have fond memories of Novell 3.11. Rock solid, just got on with it.