CIRCLE WITH A DOT

For the first time in history, a basic "spinning rust" HDD costs ~2x (per capacity) what it did 5 years ago.

We're cooked.

@lerg Having upper management take pager duty is an amazing idea.

@praetor Python is not the reason that large AI models require many GB of RAM to process efficiently.

@tychotithonus They took an LPE and made it into the most talked-about vulnerability of the year.

I think they understand the disclosure process quite well.

@tychotithonus In your view, did the discoverers of the 487 other Linux CVEs that month have such an obligation?

Or is it just for those who go out of their way to inform the users of the affected systems?

@tychotithonus I just can't see how finding a bug using AI-guided fuzzing techniques obligates a security researcher to include LLM-generated guidance for defenders in their disclosure.

I think defenders can consult their own chatbots if they wish.

There are approximately 488 Linux kernel CVEs per month* and not a lot of reason to think that CVE-2026-31431("copy .fail") is particularly special.

- It's an LPE (local privilege escalation). Yes, we should take it seriously and never give up the dream. No, you should not rely on non-virtualized containers to provide a true multi-tenant security boundary.

- Every potential attacker in the world has been able to observe the vulnerability in source code form since mid-2017 (9 years ago).
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=72548b093ee38a6d4f2a19e6ef1948ae05c181f7

- The vendor was notified of the vulnerability 2026-03-23 (39 days ago), apparently with enough detail to put together a patch in ~3 days.

- Every potential attacker in the world was informed of the specific vulnerability 30 days ago (2026-03-31 at the latest) when the patch was committed with the header "Reported-by: Taeyang Lee <0wn@ theori. io>" Theori .io advertises both offensive and defensive security information services on their site.
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/commit/?id=a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5

The researchers:

- Notified the kernel security team
- Observed the patch committed
- Waited another 34 days
- Published a detailed writeup

Professionally done, IMO.

The researchers followed the process outlined on the affected vendor's website. Specifically:
"the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL...[list that includes some absurdly vague conditions]"
https://docs.kernel.org/process/security-bugs.html

To do much more than follow the vendor's preferred disclosure process often amounts to demanding that *your* bug be given special attention and treatment. Which is a thing researchers sometimes do. Naturally it's hard to be objective about one's own finding.

Assessing and prioritizing bug reports is generally the job of the *vendor's* security team, *not* the researchers. There are exceptions. But to force special handling for your bug is simply to blindly take resources away from all the reports that will lead to the 487 other CVEs that month. And some of those might not be LPEs. They could be wormable remote network holes or virtual machine breakout bugs.

In this case, the kernel security team appears to have decided that the appropriate response was to let downstream read about it when the patch was committed to source control like everybody else. A CVE was publicly announced 11 days later, for a total of 30 days after being notified.

There are far worse systems.

Regardless, that process is theirs to manage. It's between the Linux kernel team and whoever they have made promises to.

I don't know about you, but I get my Linux for free. Nobody promised me anything.

* Data from stack .watch/product/linux/linux-kernel/, 14 month average

@Lioh OK, so what’s your preferred vulnerability disclosure policy?

Just linking the document is fine.

@Lioh Reporting security vulnerabilities is a worse-than-thankless job.

@Lioh They reported the bug to the Linux kernel security team over a month ago. A CVE was issued. I don’t know where the ball was dropped but, AFAICT, not a single distro took it seriously enough to release a patch.

It’s not the bug reporter’s job to run a testing service for everyone (mostly large for-profit companies) downstream of the Linux kernel.

@rootwyrm @wdormann https://hachyderm.io/@dalias/116490206427142497

@rootwyrm @wdormann Likely just a limitation of that particular PoC

@0xabad1dea Nice.
Until the last panel, I thought it might have been the Ken Liu story *Good Hunting*. (recommended)

Thank you, 21st century.
Just what we needed.
Right on schedule.

@icing I see the critical assumptions as:

1. AI 1 is operated to not create a bad report in the first place
2. AI 2 is operated to reject a bad report
3. The AIs probability of failure at (1) and (2) are uncorrelated

If these assumptions were somehow validated, then they would constitute a “belt and suspenders” type redundant system.

But such assumptions are rarely justified in practice.

@icing If they are truly configured to operate as redundant “checks”, wouldn’t it be the *failure* rate (1 - P_success) that multiplies?

@Mastodon @sovtechfund great so you can add “copy hyperlink” support back to the iOS client then?

@adamshostack @thedarktangent We need voice chat channels and preferably screen sharing