Top
Best
New

Posted by flipped 17 hours ago

Dirtyfrag: Universal Linux LPE(www.openwall.com)
677 points | 276 commentspage 3
baggy_trough 17 hours ago|
Disclosure Timeline

2026-04-29: Submitted detailed information about the rxrpc vulnerability and a weaponized exploit that achieves root privileges on Ubuntu to security@kernel.org.

2026-04-29: Submitted the patch for the rxrpc vulnerability to the netdev mailing list. Information about this issue was published publicly.

2026-05-07: Submitted detailed information about the vulnerability and the exploit to the linux-distros mailing list. The embargo was set to 5 days, with an agreement that if a third party publishes the exploit on the internet during the embargo period, the Dirty Frag exploit would be published publicly.

2026-05-07: Detailed information and the exploit for the esp vulnerability were published publicly by an unrelated third party, breaking the embargo.

2026-05-07: After obtaining agreement from distribution maintainers to fully disclose Dirty Frag, the entire Dirty Frag document was published.

flumpcakes 16 hours ago|
7 days from disclosure to publishing a how-to guide to get root to the entire planet doesn't scream "responsible" disclosure to me.
bawolff 16 hours ago|||
Its not the reporter's fault that other people broke the embargo.
progval 16 hours ago||
They don't have to publish a working exploit as soon as the embargo is broken, though.
throw0101c 15 hours ago|||
Perhaps, but if the exploit code is published folks can double-check that they implemented the mitigations properly.

If there's no PoC, how can you really be sure?

john_strinlai 16 hours ago||||
anyone who will use the exploit maliciously will immediately and trivially be able to create a working exploit.
staticassertion 10 hours ago||||
An exploit was already published.
mike_d 16 hours ago|||
Why not? There has already been a working exploit floating around, at least now it comes from an authoritative source.
firer 16 hours ago||||
My immediate reaction was the same.

But this is very similar to Copy Fail, and I'm assuming there was an assumption that others might also discover this soon as well. Hence the urgency.

At least that's my charitable interpretation.

lofaszvanitt 15 hours ago|||
WTF cares? Publish them without disclosure is the true way, otherwise noone would care about security and your data.
snvzz 1 hour ago||
There's, in practice, unlimited such bugs in the megabytes of kernel object code.

Monolithic UNIX-like kernels are a bankrupt design.

Only third generation microkernels like seL4[0] make sense in the present world. All effort put elsewhere is wasted outright.

0. https://sel4.systems/

mikeweiss 9 hours ago||
Considering AWS just released patches for Copy Fail for Amazon Linux and Bottlerocket only yesterday.... I imagine it will over a week before we see patches for this. This is especially important to fix on Kubernetes nodes...does anyone have any recommendations for mitigating this issue before a patch is released?
caned 12 hours ago||
The enforcement of read-only protection for pagecache pages (and the scatterlists and or other structures they point to) seems to be diffuse and incredibly fragile.
jcims 15 hours ago||
Tested Amazon Linux 2023 and it doesn't appear to be vulnerable in the default configuration. Would be interested if anyone finds anything different.
fulafel 7 hours ago||
RxRPC is apparently an AFS (Andrew File System) thing.
Tiberium 17 hours ago||
Do you think with modern LLMs in a few years projects like Linux will have all those low-hanging security bugs fixed? Are we witnessing a transition period, or will nothing change?
tetha 6 hours ago||
Out of this dataset of 2-3 vulnerabilities, I'm noticing a pattern: All of those are in older and/or niche kernel modules. That raises two thoughts:

Maybe the more regularly used kernel code has a lot of low-hanging security topics shaken out of it already.

And second, I'm indeed wondering what a good path to minimize the loadable kernel code is on a system looks like. My container hosts for example have a fairly well defined set of requirements, and IPSec certainly is not in there. So why not block everything solely made to support IPSec? I'm sure there is more than that.

After all, the most reliable way to higher security is to do less things.

spartanatreyu 10 hours ago|||
LLMs don't matter, linux's codebase has been growing much faster than it can be secured so this is all inevitable.

Transitioning components to rust eliminates certain categories of bugs leaving the rest of the bugs to be dealt with.

We'd likely end up needing another language with stronger type and effect systems to eliminate more categories of bugs. Probably something which enforces linear types, capabilities, units of measure types, and effects.

And you'd have to update linux itself to switch to capabilities.

staticassertion 16 hours ago||
New vulns are introduced to Linux every day. Fuzzers trigger every single day on Linux. No, nothing will improve here from AI.
alex_duf 16 hours ago|||
there's an argument to be made that new code will be inspected before being merged and therefore the classes of bugs an LLM is likely to find will not be merged until it's fixed.
Muromec 16 hours ago|||
There is a finite number of bugs and betters tools that find them mean there is less bugs in the code.
staticassertion 16 hours ago||
We already find bugs constantly in Linux and they go unaddressed, no one even keeps up with syzkaller reports lol

AI is neat because it's higher signal but yeah no, we're not getting anywhere close to "safe linux", AI or not.

nicman23 6 hours ago|
well at least they are not commonly loaded - in like 12 machines i have
More comments...