15 comments

[ 1.2 ms ] story [ 9.1 ms ] thread
Might need to silently archive those Microsoft Patch Tuesday jokes...
https://docs.kernel.org/process/cve.html

> Note, due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team.

(And because this happens during the stable release process, there are a lot of 24-hour periods where they issue a ton of CVEs for all the minor bugs fixed in the release.)

I am assuming that many of these are found with automatic analysis tools that are very creative (i.e. LLMs) and there may be a high proportion of very "cornered" cases. I think there needs to be a triage method that would amount to the severity, likeliness, and detection dimensions used to rank risks in a systematic framework [1]. I think if this could be submitted (or estimated) along with such bug reports, it could go a long way toward sustainable intake patterns for this number of possible defects.

[1]: https://en.wikipedia.org/wiki/Failure_mode_and_effects_analy...

Linus better put his money where mouth is and fire up those AI tokens ASAP.

I don't consider this a tragedy, it's just unearthing the reality.

I guess very few around here remember the minor fuzz about this from a few years ago? The Linux Kernel Project became their own CNA (CVE Numbering Authority). A CVE is now slapped onto practically every bug fix that is back ported to a stable kernel, resulting in a flood of CVEs.

A blog post about this, published at the time: https://sigma-star.at/blog/2024/03/linux-kernel-cna/

The title is editorialized (i.e. the OP made it up), the link simply goes to the kernel CVE mailing list archive.

It's malicious-compliance CVE filing. Other interesting coverage of the issue by Risky Biz, https://news.risky.biz/risky-biz-news-the-linux-cna-mess/.

Given the broken nature of the CVE process, see for example Daniel Stenberg of cURL fame's frequent comments on this, I'm undecided whether this is a good thing, a bad thing, or a bit of both.

Amazing how people think this means anything
Good, it seems like new AI tools would lead to substantially more hardened Linux kernel long term. Until a new generation of AIs finds more bugs.
What people are missing is that these aren't vulnerabilities. The reason you see this is because Greg does not believe in the CVE system. As an act of rebellion, the Linux kernel (a) assigns CVEs to fixes and not bugs, (b) assigns them gratuitously to DoS the system.

This is just Greg being a baby. Linux has to be removed as a CNA ASAP, it was a terrible idea to ever grant them that power.

This has nothing to do with AI or even security.

Nearly every bug is at best a denial of service. If the service worked as expected, there wouldn't be any bug. CVSS considers any denial of service a security issue. Therefore, all bugs should have CVE numbers. The Linux team took this to heart, became a CNA, and assigns CVEs to pretty much every bug.
More fuel for the Asterinas kernel, coming for Linux with a purely Rust kernel.
This should be considered unethical tbh.