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.
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.
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.
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.
Setting aside the merits of DEI, this anecdote isn't indicative of it. I recall a client getting HP to do a security audit of a site I was working on, and it absolutely read like a committee put together a checklist of every possible thing they could think of. They flagged that user sessions weren't pinned to IP addresses, despite this being right around the time that cell phones became popular and their suggested remediation would have caused users who were riding on a bus between cell towers to get logged out while they were using the site.
There were plenty of even less useful flags, but that one stood out to me for some reason.
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.
> 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.
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.
> 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.
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.
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?
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. :)
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.
> 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.)
[1]: https://en.wikipedia.org/wiki/Failure_mode_and_effects_analy...
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??
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.
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.
There were plenty of even less useful flags, but that one stood out to me for some reason.
"Checklist security" has been a thing for ages.
Most businesses run on a, "least to be in compliance" model.
> 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.
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.
https://www.bleepingcomputer.com/news/microsoft/microsoft-ju...
https://blog.desdelinux.net/en/virus-in-gnulinux-reality-or-...
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.
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.
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.
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.
Your phone is ringing, caller ID says its Theo de Raadt from OpenBSD. :)
Nothing to panic about.
We are going to see more of this with LLMs being able to uncover hundreds of bugs in projects just like Linux.
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.
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.
[0] https://docs.kernel.org/process/coding-assistants.html
Go Greg!!
https://en.wikipedia.org/wiki/Greg_Kroah-Hartman
http://www.kroah.com/linux/
I don't consider this a tragedy, it's just unearthing the reality.
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. :)