Top
Best
New

Posted by flipped 18 hours ago

Dirtyfrag: Universal Linux LPE(www.openwall.com)
692 points | 283 commentspage 4
x4132 15 hours ago|
this is why you don't contact distro mailing list. responsible disclosure is dead.
zbentley 14 hours ago|
At present it looks to me like the embargo was broken by someone identifying the patch as fixing a vulnerability, not someone leaking the mailing list.

More information may come out, or I might be missing something, but assuming that the above is accurate, this isn't a problem with responsible disclosure or mailing list opsec; it's a problem with the nature of open source. Right? Or are folks seriously proposing that the patch/mitigations should have been circulated to distro maintainers privately before going to mainline?

collinmanderson 14 hours ago||
> Or are folks seriously proposing that the patch/mitigations should have been circulated to distro maintainers privately before going to mainline?

I always assumed that distro maintainers got early access to patches before going mainline but maybe that’s not true?

baggy_trough 13 hours ago||
From the 3rd party discloser:

https://openwall.com/lists/oss-security/2026/05/07/12

nicman23 7 hours ago||
well at least they are not commonly loaded - in like 12 machines i have
teaearlgraycold 15 hours ago||
Anyone here with experience providing multi-tenant Linux systems (CI and the like), do providers usually disable kernel modules they don’t need to eliminate attack surface? Every time one of these comes out I wonder if I should be rotating every key in my GitHub CI or PaaS host. So far I haven’t seen any reports from the providers I use that they were pwned by any of these exploits.
TheDong 10 hours ago|
A lot of these multi-tenant CI systems actually run everything in microVMs even if they present it to you as a container.

At this point, a microvm can be booted in ~200ms so you don't even have to keep a warm pool, you can just launch em on demand.

GitHub CI (actions) uses virtual machines.

BadBadJellyBean 17 hours ago||
Well this is getting tiresome. I wish there was a less stressful way to get fixes for such bugs. But the cat is out of the bag now.

Not criticizing whoever found the bug, of course.

oncallthrow 17 hours ago||
can this also be used to obtain container escape ?
synack 17 hours ago|
If your container has setuid binaries and these modules are loaded, yes.
lights0123 17 hours ago|||
With the exploits published as-is, you'll only get root inside the container: there's no explicit namespace break, and calling setuid() in a container just gives you root in the container.

However, it can be used to modify files that are passed into the container (e.g. Docker run -v), or files that are shared with other containers (e.g. other Docker containers sharing the same layers). kube-proxy with Kubernetes happens to share a trusted binary with containers by default, which is how it can be exploited: https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...

miduil 16 hours ago||||
It's poisoning the filesystem cache, if you don't have a setuid binary handy you just poison anything else that gets executed by the host.
aaronmdjones 13 hours ago||||
You don't need any setuid binaries. You could just as easily use the vulnerability to add a job to crontab(5) that causes the cron daemon to run whatever you want as root.
awoimbee 16 hours ago|||
And your containers need to have specific capabilities enabled, which aren't by default on kubernetes and podman.
friedr12 14 hours ago||
[dead]
unethical_ban 17 hours ago|
Here's a general question, are these vulnerabilities hitting Linux more than BSDs due to hit being a larger target or because its architecture is less secure by design?
vsgherzi 16 hours ago||
It’s two things. 1. Less eyes are on the bsds

2. Bsds don’t have the same optimizations that Linux has. Bsds generally try to pursue corrrectness

That being said there were just a bunch of vulnerabilities in freebsd

macOS has had its own dirty cow attack and I know there’s for sure more memory ones just based on the way the xnu kernel works.

So no Linux isn’t really worse per say

staticassertion 17 hours ago|||
Larger target.
golem14 16 hours ago||
in many ways:

- more people are using it (assuming macos is in its own bucket perhaps) - bigger surface areas (esp NetBSD has in my limited understanding just less stuff that can go boom) - more churn, ie more new stuff than can be buggy released more often.

Of course, because of that, more eyes are on Linux, so I'm not sure where that security tradeoff is.

ahartmetz 17 hours ago||
AFAIU, Linux and the BSDs have basically the same architecture - the BSDs just value secure and simple, understandable code more highly than Linux vs features and performance.
angry_octet 16 hours ago||
This is really not a correct statement beyond the fact that both are a type of Unix.
cluckindan 16 hours ago|||
Linux is not Unix: it is not derived from AT&T Unix.
angry_octet 5 hours ago|||
By that definition, nor is BSD. It's kind of their whole raison d'étre.
ahartmetz 15 hours ago|||
Linux 2.2 or 2.4 or so (possibly only Suse Linux) even had a kernel startup message "Unix compliance testing by UNIFIX" or something, back when Unix was considered more prestigious than Linux. It is / was by some official definition "a Unix", though not "UNIX the trademark by AT&T".
cluckindan 14 hours ago||
I’m fairly certain they’re referring to POSIX compatibility, not calling a Linux a Unix.
ahartmetz 14 hours ago||
Oh damn, you are probably right.
ahartmetz 15 hours ago|||
What are the differences? I think of both as Unix-type sytems with macrokernels. I have no practical experience with BSDs.
ahartmetz 1 hour ago||
Jeez, care to reply instead of downvoting? I would really like to know. I do keep an eye on the BSDs as a good example in some areas where Linux is bad.
More comments...