Fragnesia Made Public As Latest Linux Local Privilege Escalation Vulnerability (phoronix.com) 22
A new Linux local privilege escalation flaw called Fragnesia has been disclosed as a Dirty Frag-like vulnerability, allowing arbitrary byte writes into the kernel page cache of read-only files through a separate ESP/XFRM logic bug. Phoronix reports: Proof of concept code for Fragnesia is already out there. There is a two-line patch for addressing the issue within the Linux kernel's skbuff.c code. That patch hasn't yet been mainlined or picked up by any mainline kernel releases but presumably will be in short order for addressing this local privilege escalation issue. More details can be found here.
Year of the Patch (Score:4)
Patchfest 2026 is going strong.
Re: Year of the Patch (Score:5, Informative)
Just the thing to erode public perception of the security of open source operating systems that also don't fit into a master plan of making everyone register themselves for remote identification in some way to "protect young people from harmful content".
Re: Year of the Patch (Score:4, Interesting)
Re: (Score:1)
This is nothing new. All we're seeing is a concerted attempt to erode what little public trust Linux has gained over the past 3 decades. Running Linux in the 90's was no different; people viewed it and its proponents with fear and mistrust. I'm not sure however that the intervening years of viewing us merely with comedic disdain was overall that much better though.
Re: (Score:2)
This sort of thinking, i.e., everything should have price tag associated with it, is becoming pervasive throughout the American economy. It is pernicious and threatens not only open source but gov. agencies, programs, etc. Even CongressCritters are not immune, they always seem to come with a price tag, sometimes several depending upon which one they'll need in a given situation.
Re: (Score:3)
It's the realization that the old "many eyes make all bugs shallow" thing was never really true. Once code is working, people tend to ignore it. Only NSA types were doing proper security audits. Once AI tools became available to find bugs, this was inevitable.
Same thing happened with Firefox. Turned AI on it, found hundreds of bugs, many of the security related. The fact that only 3 people use Firefox now is probably all that saved it from being exploited earlier.
Re: (Score:2)
I'll use LibreWolf in the meantime. Oh, also, I do almost nothing with it. That helps.
Disclosure Timing Drama Part 2.0 (Score:4)
Looks like this time around the disclosure happened when the patch hit netdev. This was even faster than the drama that happened around the Dirty Frag embargo [slashdot.org]. Meant that no one else could back-engineer and release the vulnerability before the original reporters, but also a greater amount of time between disclosure and when the patches hit downstream distros.
I wonder if that last case of back-engineering on prerelease kernels is going to set a new norm on disclosure timing. If people can back-engineer then getting the mitigations out as quick as possible is more important than trying to hide the issue until the kernel patch actually drops for distros.
Re: (Score:3)
For a local elevation? Probably. The longer disclosure times clearly have stopped working. But I shudder to think what happens when somebody finds a remote vulnerability...
Re: (Score:2)
The bigger challenge is how are projects going to discuss any not so trivial to patch issues? As long as the fix is encode this, duplicate that and only provide the copy to the caller, and what not, the situation is manageable.
The moment we hit something where the fix likely means changing behavior and needs design discussion enough hints are going to drop that even in absence of patch file that would highlight the exact lines of affected code even a relatively low skill actor is going to be able t
Re: Disclosure Timing Drama Part 2.0 (Score:2)
I suspect part of it is that the mitigation for DirtyFrag covers it, so everyone who blocked all the modules in question when that had only an incomplete patch probably hasn't unblocked them yet. I think this is the 4th patch for these modules, and only got a new name rather than just "there's still a way to get this code to do the wrong thing" because a different outside team found this one.
Re: (Score:3)
You are correct. The mitigation of banning of the modules for Dirty Frag also covers Fragnesia.
However, if you removed the mitigation after getting a patched kernel, the previous patches do NOT protect against Fragnesia, so you will have to mitigate again until the kernel is patched again.
Re: (Score:2)
Now anyone can throw the kernel source code, and any publicly submitted patches, at AI, the idea that you can just keep quiet about a vulnerability until everyone gets around to patching it is questionable at best. The chances of the same flaw being discovered in parallel have massively increased.
Big companies that run millions of servers can at least detect when vulnerabilities are being exploited in the wild, and delay disclosure until that point or until the patch is widely implemented. Not so easy for o
AI (Score:2)
How many of these bugs is the AI, all of them -- skynet basically, keeping in its back pocket for blackmail or global takeover purposes?
Re: (Score:2)
This is nothing (Score:4, Interesting)
If you think this is starting to get frightening, imagine the bug list at Microsoft after running an AI audit to Windows code base. I still think this is for the better, but the next year or two will be interesting, to say the least.
General solution (Score:2)
Re: (Score:3)
Sooo.... will it work to root android maybe? (Score:2)
Can we use any of them to get root on any unpatched phone?
Re: (Score:3)
DirtyFrag does not work on Android https://github.com/V4bel/dirty... [github.com]
Same Mitigation as Dirtyfrag (Score:2)
blacklist: esp4 esp6 rxrpc
If you already did it for dirtyfrag you're good.