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.
> 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.
The linux kernel team disagrees with your approach but what do they know?
> 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.
I only sampled them, but all the ones I sampled are announcements of fixes, not just vulnerabilities. This seems to be downstream of the "intake" already.
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.
Those that actually understood security, and weren't on some kind of open-source enforcement mission in life, always knew the "Linux doesn't get viruses" statements would not age well.
If they were there this whole time but only discovered now, were they really a threat? The reflexive response to this is "those could be exploited for years and we'd never know", but if it was discovered, it obviously wasn't impacting you personally. If they were under lock and key at the NSA and only judiciously used for secret spy BS, that's effectively the same as not existing. Clearly they weren't discovered by all the white hats for this whole time.
Also, if Microsoft hypothetically open sourced their code, do you think there would be more, less, or the same number of CVEs? I would guess more.
I don't want to go too far to defend Linux. I want to make the case that it has been the more secure OS this whole time.
You do realize this is an announcement of already fixed issues which were fixed (and not just flagged) weeks or months ago, right? Or are you claiming that Chinese models allow for time travel?
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.
(Email the mods to clear up the editorial title problem; footer contact link.)
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...
In my company, the security team isn’t technical. They see CVE, find a vulnerable system, it gets flagged. We have to patch it.
We patched for a CVE last week that a malicious usb sound card device could be use the gain root.
On a Vm? Is that something we really need to worry about??
The linux kernel team disagrees with your approach but what do they know?
> 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.
I only sampled them, but all the ones I sampled are announcements of fixes, not just vulnerabilities. This seems to be downstream of the "intake" already.
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.
Might need to silently archive those Microsoft Patch Tuesday jokes...
Don't worry, Microsoft is still leading:
https://www.bleepingcomputer.com/news/microsoft/microsoft-ju...
Those that actually understood security, and weren't on some kind of open-source enforcement mission in life, always knew the "Linux doesn't get viruses" statements would not age well.
https://blog.desdelinux.net/en/virus-in-gnulinux-reality-or-...
If they were there this whole time but only discovered now, were they really a threat? The reflexive response to this is "those could be exploited for years and we'd never know", but if it was discovered, it obviously wasn't impacting you personally. If they were under lock and key at the NSA and only judiciously used for secret spy BS, that's effectively the same as not existing. Clearly they weren't discovered by all the white hats for this whole time.
Also, if Microsoft hypothetically open sourced their code, do you think there would be more, less, or the same number of CVEs? I would guess more.
I don't want to go too far to defend Linux. I want to make the case that it has been the more secure OS this whole time.
More useful context http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignmen...
Nothing to panic about.
Amazing how people think this means anything
This sounds like cope.
We are going to see more of this with LLMs being able to uncover hundreds of bugs in projects just like Linux.
All these seem to be by the same person.
Go Greg!!
https://en.wikipedia.org/wiki/Greg_Kroah-Hartman
http://www.kroah.com/linux/
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.
Chinese models, hurray!
You do realize this is an announcement of already fixed issues which were fixed (and not just flagged) weeks or months ago, right? Or are you claiming that Chinese models allow for time travel?
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.
What does any of this have to do with AI?