Stupidity [LWN.net]

Stupidity

Posted May 7, 2026 23:53 UTC (Thu) by jpeisach (subscriber, #181966)
Parent article: Dirty Frag: a zero-day universal Linux LPE

Two wrongs don't make a right.

"Oh, someone broke the embargo. Looks like it's technically public. Let's all publish it on GitHub, advertise it so many more people can see it while THERE IS NO PATCH AVAILABLE."

Do better.

to post comments

Stupidity . . . or not

Posted May 8, 2026 0:02 UTC (Fri) by himi (subscriber, #340) [Link] (6 responses)

Quoting from the README.md on the repo:

> Because the embargo has currently been broken, no patch or CVE exists. After consultation with the
> maintainers on linux-distros@vs.openwall.org and at their request, this Dirty Frag document is being
> published. For the disclosure timeline, refer to the technical details.

In other words, the publication of this information was done in consultation with, and at the request of, the kernel and distro security groups - not something that deserves to be called "stupidity". Particularly given there's a pretty simple mitigation (blacklisting and removing the vulnerable modules).

Stupidity . . . or not (and apologies)

Posted May 8, 2026 0:07 UTC (Fri) by jpeisach (subscriber, #181966) [Link] (5 responses)

> In other words, the publication of this information was done in consultation with, and at the request of, the kernel and distro security groups - not something that deserves to be called "stupidity". Particularly given there's a pretty simple mitigation (blacklisting and removing the vulnerable modules).

Yes, but now there is actual public discourse on this, so it can be exploited.

Also: stupidity wasn't appropriate, I should've just said that I strongly disagree with the approach.

Stupidity . . . or not (and apologies)

Posted May 8, 2026 0:33 UTC (Fri) by Nahor (subscriber, #51583) [Link]

And there is also much public discourse on the uselessness of embargoes with the advent of LLMs, that they now protect the exploiter as much as the exploited.

Stupidity . . . or not (and apologies)

Posted May 8, 2026 1:57 UTC (Fri) by Heretic_Blacksheep (guest, #169992) [Link] (3 responses)

It would be negligent if there weren't workarounds that most people could deploy immediately assuming they don't use kernel IPSEC in their environment in this specific case. Once the embargo is broken, it's *broken*. The cat is out of the bag and there's no putting it back in. This *is* the responsible thing to do for the community. We don't live in a binary world (pun intended). From any given POC, obscure origin or not, there's only a few hours on average before exploitation begins. Prepare to see a lot more of these as people use *LMs to summarize and engineer exploits as soon as patch code becomes public regardless of embargo status.

Embargos are becoming obsolete in a world where anyone can deploy LM tooling to summarize fixes and produce chained exploits in moments. Every scriptkiddie has the potential to deploy fully functional, sophisticated attack tools now. Open source or closed source are immaterial because the LMs can also reverse engineer machine code. This will be the norm until all the low hanging (read financially/resource cheap) fruit is already picked.

Stupidity . . . or not (and apologies)

Posted May 8, 2026 7:29 UTC (Fri) by gf2p8affineqb (subscriber, #124723) [Link] (2 responses)

Are there actual examples of LLMs finding security bugs through disassembly at scale? Or is that conjecture on your part.

Stupidity . . . or not (and apologies)

Posted May 8, 2026 9:02 UTC (Fri) by eru (subscriber, #2753) [Link]

You could use Ghidra to decompile code, then use LLM on the result.

Stupidity . . . or not (and apologies)

Posted May 8, 2026 10:41 UTC (Fri) by justincormack (subscriber, #70439) [Link]

Yes there is this RCE bug in GitHub that was found through reverse engineering of the GitHub Enterprise binaries https://www.wiz.io/blog/github-rce-vulnerability-cve-2026...

A work around is available.

Posted May 8, 2026 1:21 UTC (Fri) by ebiederm (subscriber, #35028) [Link]

Most people should be able to disable loading the problem modules.

Stupidity

Posted May 8, 2026 14:55 UTC (Fri) by mirabilos (subscriber, #84359) [Link] (1 responses)

Agreed.

They ought to have held their feet still until patches are available.

Even if someone else “broke embargo”, just publish mitigations (block kernel modules X, Y and Z or W) until then.

Stupidity

Posted May 14, 2026 10:59 UTC (Thu) by madhatter (subscriber, #4665) [Link]

> Even if someone else “broke embargo”, just publish mitigations (block kernel modules X, Y and Z or W) until then.

If you mean "publish mitigations without the full explanation", I can't agree. In this case, the mitigations will be worse than the disease: on all my IPSec collapse points, for example, the mitigation would completely disable all my VPN links. Just telling me "do that" is, well, very disruptive, to say the least.

But when I have the full details, I can also see that the exploit requires an unprivileged user account. Since none of my collapse points have user accounts for anyone that isn't also a sysadmin with full sudo privileges, I know that I am no more exposed by this vulnerability than I was before it was discovered, and I can make a reasoned judgement about whether this justifies taking down all VPN links across the enterprise.

I do not think there is ever a justification for revealing less information than has elsewhere been revealed, merely in the hope that people won't find the elsewhere. If that wasn't what you were suggesting, then I apologise for getting the wrong end of the stick.

Stupidity

Posted May 9, 2026 10:14 UTC (Sat) by muase (subscriber, #178466) [Link]

No, and that stance is also objectively wrong.

If you can reasonable assume that an exploit is unknown to others, it can make sense to keep it secret until patches deployed. However, if there is only a slight realistic chance that an exploit is known to other, less benevolent actors, it becomes paramount to thoroughly inform the users. You should give them all the information and tools so they can apply mitigations, do some risk analysis and tests for their specific setup, or even just identify and take vulnerable systems offline.

Intentionally not informing your users if your product puts them in danger is objectively malevolent behavior – up to the point that in other contexts that can even lead to legal consequences (rightfully so).