Brief items

Dirty Frag: a zero-day universal Linux LPE

Hyunwoo Kim has announced the Dirty Frag security flaw, a local-privilege-escalation (LPE) vulnerability similar to the recently disclosed Copy Fail flaw:

Because the embargo has now been broken, no patches or CVEs exist for these vulnerabilities. After consultation with the linux-distros@vs.openwall.org maintainers, and at the maintainers' request, I am publicly releasing this Dirty Frag document.

As with the previous Copy Fail vulnerability, Dirty Frag likewise allows immediate root privilege escalation on all major distributions.

Kim, who discovered the flaw and had attempted a coordinated disclosure set for May 12, has released the code for an exploit, as well as a example script to remove the vulnerable modules. A full write-up, with the disclosure timeline, is also available. It's unknown at this time whether this is an example of parallel discovery or how the third party was able to disclose it prior to the end of the embargo. We will be following up as more information comes to light.

Comments (36 posted)

Yet another Dirty Frag type vulnerability: Fragnesia

Sam James has sent an announcement to the OSS Security mailing list about another local-privilege-escalation (LPE) exploit in the same class as Dirty Frag, called "Fragnesia". From the disclosure:

This is a separate bug in the ESP/XFRM from dirtyfrag which has received its own patch. However, it is in the same surface and the mitigation is the same as for dirtyfrag.

It abuses a logic bug in the Linux XFRM ESP-in-TCP subsystem to achieve arbitrary byte writes into the kernel page cache of read-only files, without requiring any race condition.

James noted that there is a patch in the works, but it has not yet been pulled into Linus Torvalds's tree nor into any of the stable kernels. A proof of concept exploit is also available.

Comments (29 posted)

Stenberg: Mythos finds a curl vulnerability

Daniel Stenberg has published a lengthy article on his thoughts on Anthropic's Mythos, which the company decided was too dangerous for wide public release.

My personal conclusion can however not end up with anything else than that the big hype around this model so far was primarily marketing. I see no evidence that this setup finds issues to any particular higher or more advanced degree than the other tools have done before Mythos. Maybe this model is a little bit better, but even if it is, it is not better to a degree that seems to make a significant dent in code analyzing.

This is just one source code repository and maybe it is much better on other things. I can only tell and comment on what it found here.

But allow me to highlight and reiterate what I have said before: AI powered code analyzers are significantly better at finding security flaws and mistakes in source code than any traditional code analyzers did in the past. All modern AI models are good at this now. Anyone with time and some experimental spirits can find security problems now. The high quality chaos is real.

Comments (36 posted)

Kernel release status

The current development kernel is 7.1-rc3, released on May 10. Linus said: "I think this answers the 'is 7.1 continuing the larger size pattern that we saw with 7.0?' question, and the answer is yes: that wasn't a fluke brought on by a .0 release - it simply seems to be the new normal."

The 7.1 kernel has, to date, brought in 13,922 non-merge changesets from 2,141 developers, 395 of whom are first-time kernel contributors. The release history looks like:

RC	Date	Commits
v7.1-rc1	2026-04-26	13963	13963
v7.1-rc2	2026-05-03	475	475
v7.1-rc3	2026-05-10	584	584

See the KSDB 7.1 page for more details.

Stable updates were not in short supply. 7.0.4, 6.18.27, and 6.12.86 were released on May 7. 6.1.171, 5.15.205, and 5.10.255 were released on May 8, followed some milliseconds later by 7.0.5, 6.18.28, 6.12.87, 6.6.138 6.1.172 and 5.15.206. 7.0.6 and 6.18.29 then wandered in on May 11. This pace may continue for a while if the onslaught of LLM-driven vulnerability reports does.

The 7.0.7, 6.18.30, and 6.12.88 updates are in the review process; they are due on May 14.

Comments (none posted)

killswitch for short-term emergency vulnerability mitigation

It seems that we are in for an extended period of the disclosure of vulnerabilities before fixes become available. One possible way of coping with this flood might be the killswitch proposal from Sasha Levin. In short, killswitch can immediately disable access to specific functionality in a running kernel, essentially blasting a vulnerable path (and its associated functionality) out of existence until a fix can be installed. "For most users, the cost of 'this socket family stops working for the day' is much smaller than the cost of running a known vulnerable kernel until the fix land."

Comments (59 posted)

Quotes of the week

I have one final question for you, given that I have been worried about RCU pointer leaks for many years, but I have not heard of many actually happening. Is this because Linux-kernel developers are admirably careful with their RCU read-side critical sections? Or is it because RCU grace periods are normally long enough that these developers are getting away with egregious RCU pointer-leak bugs? ;–)

— Paul McKenney

I think we should simply make it a rule that "a 'security' bug that is found by AI is public".

Now, I may be influenced by that "my inbox is a disaster during the merge window" thing, but I do think this is pretty fundamental: if somebody finds a bug with more or less standard AI tools (ie we're not talking magical special hardware and nation-state level efforts), then that bug pretty much by definition IS NOT SECRET.

So why should be consider it special and have it be on the security list?

— Linus Torvalds

Comments (none posted)

Debian to require reproducible builds

Paul Gevers has slipped an interesting bit of news into a "bits from the release team" message:

Aided by the efforts of the Reproducible Builds project, we've decided it's time to say that Debian must ship reproducible packages. Since yesterday, we have enabled our migration software to block migration of new packages that can't be reproduced or existing packages (in testing) that regress in reproducibility.

As Gioele Barabucci pointed out, "reproducible" in this sense is limited to building within an instance of Debian's build environment, which is a tighter requirement than is normally used. It is still a big step forward for reproducible builds.

Comments (24 posted)

Distributions quote of the week

Here's Adam's Highly Non Politically Correct Take He Hopes Nobody Too High In His Management Chain Sees: RH wanted a big splashy announcement for Summit, and now it's got one.

If you believe that RH is sufficiently nimble, organized and internally-communicative that it is entirely certain what it actually wants Fedora Hummingbird to be already, somebody in PR needs a massive raise, cos I bet we don't. 😛

Now the Summit thing is done the types of people who care a lot about getting announcements done for Summit will relax, and the rest of us can get on with the business of figuring out what the thing is actually going to be...

— Adam Williamson on the surprise (to the Fedora community) announcement of Fedora Hummingbird.

Comments (none posted)

An update on KDE's Union style engine

Arjen Hiemstra has published an article on the status of the Union project: a single system to support all of KDE's technologies used for styling applications.

The work on Union's Breeze implementation has progressed to the point where it is very hard to distinguish whether or not you are running the Union version. We have also tested with a bunch of applications and made sure that any differences were fixed. So we are at a stage where we need to get Union into the hands of more people, both to get extra people testing whether there are any major issues, but also to have interested people creating new styles.

This means that with the upcoming Plasma 6.7 release, we plan to include Union. Discussion is currently ongoing whether we will enable it by default, but even if not there will be a way to try it out.

See Hiemstra's introductory article on Union, published in February 2025, for more about the project and its creation. KDE 6.7 is expected to be released in mid-June.

Comments (none posted)

Development quote of the week

Our mastodon media retention settings don't seem to have been cleaning up automatically? I'm running tootctl media remove manually now to try to bring our storage usage back under control.

We have over 100GB of remote mastodon avatars and profile images. Meanwhile my usenet archive (mirror of utzoo) from 1982 through the early 90s is only 9.5GB. Maybe we should go back to NNTP.

— Trammell Hudson

Comments (3 posted)

Sovereign Tech Fund invests in KDE

The KDE project has announced that it has been awarded over €1 million from the Sovereign Tech Fund to improve its desktop-environment software. "The investment will be used to strengthen the structural reliability and security of KDE's core infrastructure, including Plasma, KDE Linux, and the frameworks underlying its communication services."

Comments (1 posted)