Over 400 Linux CVEs published in the last 24 hours alone
lore.kernel.orgI 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.
(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??
Its the same at most orgs. Very rare for a vuln remediation program to utilize a truly risk based approach. They would have to trawl through and understand thousands of vulns and the context of your org. There's probably a market for some tool to accomplish this if the larger players haven't attempted already.
They see their dashboard, when the number is high, they want to get the number low as fast as possible. If the number is close to zero, they want to see zero. It is that simple.
They do not care if the issue is in a piece of code that is never executed and would require full access to the machine. It is there and tool X reports it.
Even security audits are terrible, when they don't find anything major they start reporting stuff that few percent of companies have implemented just to stuff their reports, it is ridiculous.
On a headless VM, almost certainly it's not a worry, since that bug needs a physical port and the driver binding to a plugged-in device (so basically it's never reached). You could even prove it running lsmod showing the module is not loaded (so "not applicable"). Unfortunately the CVSS score doesn't carry reachability information, and not just for the kernel CVEs.
It's asymmetric warfare. It costs them little to demand a false positive be acted upon, but costs you plenty to refute it.
This is the rot that's happening in cybersec. Before we even had security teams as a dedicated role, sysadmins mostly handled security, and we would evaluate each CVE and determined if it even was applicable.
Then companies started hiring paper pushers into security roles and discretion no longer mattered, it just became a game of "Check the box" with no regard for what is actually running in prod, or whether you're actually vulnerable.
Same shit with auditors. I deal with PCI and it's a fight to explain why the "compensating controls" work to a non technical auditor. If it doesn't check the box exactly, good luck.
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.
That with LLMs being decent at chaining exploits suddenly very difficult issues can be accomplished by people with middling abilities and resources.
I was too busy waxing my armchair and didn't do any reading on the actual practices. Thank you for replying with this. It makes sense. I wonder if this level of purity will survive the test of time; since there are paid kernel developers, the situation could be very different from e.g. an entirely volunteer-maintained project.
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...
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.
> I want to make the case that it has been the more secure OS this whole time.
Your phone is ringing, caller ID says its Theo de Raadt from OpenBSD. :)
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-...
You should be careful not to conflate viruses and CVEs.
Considering no Linux distro come with an antivirus by default, Linux as a desktop was always extremely vulnerable to bad actors.
As a server, I would argue otherwise.
> Linux as a desktop was always extremely vulnerable to bad actors.
Most distros people use as a desktop are alarmingly insecure by default,the security model lags well behind macOS and even Windows (again, by default. You can of course do work to harden it).
You lose out on hardware verified boot with signed system volumes, virtualization backed security, granular runtime permissions (apps having full R/W on ~Home, screen recording, microphone access).
Immutable distros like Silverblue, flatpak are moving linux desktop security in the right direction but its far from the default, and there are still gaps that need to be closed.
We (Linux community) loves to criticize security through obscurity, but that's exactly what most desktop linux users are relying on to not get pwned, relying on marketshare being so low that there just hasn't been that many incidents.
Conflated terms because they've been that way for a very long time. If you're being strict, all computer viruses stopped being a problem a decade ago.
> Those that actually understood security....
Indeed, and those who actually understood software development always knew vulnerabilities can occur just as easily as bugs.
And in some cases more easily than bugs, because many of modern vulnerabilities are so subtle, especially where crypto is involved.
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.
This has nothing to do with LLMs.
That doesn't excuse the point. Thanks to LLMs, We'll see more of this and more embargoed vulnerabilities now revealed like this on a regular basis.
Given that Linux allows the use of AI assistance [0] you'll be very disappointed to see that people will use LLMs to find even more CVEs and bugs much quicker. That also means they will be fixed much quicker which should be a good thing; as long as the core developer is in the loop checking.
Unless you are against or downplaying this, you may not know that you are actually coping.
Coping with what? Your reply is too full of buzzwords and vague assumptions to understand what point you are trying to make or what you believe you have inferred from me.
What do you use instead and what makes it more secure?
> CVE-2026-64012: net/sched: sch_sfb: Replace direct dequeue call with peek and qdisc_dequeue_peeked.
You are right, its over.
On a more serious note. Yes and no. The kernel is secure. It is probably the most scrutinized piece of software in existence. LLMs will find things but most probably they just will help contributors fix bugs.
You would think after all those years of Linus rejecting code and calling it "garbage" like some petulant manchild, there would be no garbage in the kernel...
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.
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.
More fuel for the Asterinas kernel, coming for Linux with a purely Rust kernel.
This should be considered unethical tbh.
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?
There has been a long discussion and "conflict" of opinions regarding the use of AI in kernel dev.
Linus is pro-AI as a tool ( and I mostly agree, there are consequences however that at least need to be talked about ). That's why I was talking about firing up those AI machines and fix those CVEs ( "make no mistakes" ).
But it seems every Linux topic related to security or languages is the ultimate mine field for knee-jerk reactions. :)