The Linux Kernel Is Approaching 2,000 CVEs Per Release

malaizhichun

malaizhichun

With the proliferation of AI/LLM models analyzing the Linux kernel's vast codebase, there has been a surge in the number of CVEs per kernel release. After typically being around 500 CVEs fixed per release, we are now approaching 2,000 CVEs fixed per release and perhaps will break that threshold for Linux 7.3.

Ahead of the Kernel Recipes 2026 event taking place 21 to 23 September in Paris, France, Greg Kroah-Hartman shared a teaser of his upcoming talk. He shared a slide showing the Linux kernel CVEs per release from the latest Linux 7.2 back through Linux 6.9. From Linux 6.9 through Linux 6.19 was averaging around 500 CVEs fixed per release while since Linux 7.0 it's been beyond one thousand per release. Another big step up with Linux 7.2 when breaching 1,500... If the generative AI keeps up, it's likely imminent surpassing two thousand CVEs per release.

With the Linux kernel source tree around 40 million lines, there remain many potential vulnerabilities for LLMs to discover. Fortunately, most often they end up being lower priority vulnerabilities and often within old/obscure driver code, so the impact is often minimal. Though with AI era and the superfluous bug/security reporting has also been a driving factor this year for clearing out lots of obsolete kernel code.
Linux kernel CVEs
 
I think the graph/premise is also a bit misleading.
From 6.9 to 6.19 how did they find the CVEs? Manually? "Dumber" tools?
Run the current AI/LLMs against 6.9 to 6.19 and see what the numbers are.
 
gotnull said:
I guess certain things never change. OP is still spreading Linux news on FreeBSD forum in 2026 ... one must love controversies and scandals.
Click to expand...
This is highly relevant to FreeBSD.

It is unlikely that the number of bugs per line is significantly different between Linux and FreeBSD's kernel.
 
I beg to differ, Linux is a target of corporate hit and go for decades now. Linus did meticulously scrutinize many of those commits back then, but with Microsoft, Intel and every second company directly contributing to the project.

Besides, CVE and LOC aren't corelated, a 10k LOC solo project will have less types and less instances than a 5k 4 people one. Programming style and understanding of a developer creates a CVE and we are all different.
 
cracauer@ said:
This is highly relevant to FreeBSD.

It is unlikely that the number of bugs per line is significantly different between Linux and FreeBSD's kernel.
Click to expand...
Even if you might be right, I don't buy it.

I still wait for OP's first news related directly to BSD in 7 years ... all of them talk about Linux at some point.
It feels awkward, I might be wrong but I wonder if he even runs any BSD OSes.
 
The Linux kernel has a very liberal interpertation of what should be a CVE: "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"

For example, looking at this list, the top one is currently CVE-2026-80591 requires corrupted on-disk metadata on the f2fs filesystem. Let me carefully suggest that you've already lost if an attacker can corrupt your filesystem.

This is a "assuming the bank robber has unfettered access to the bank vault, they can pilfer it" type issue. Not really a "security bug" as commonly understood.

It's also very likely literally no one has run in to that bug by the way, and one has to wonder if it's even a bug in the first place.

In general using CVEs to track "security issues" is very flawed because it's gamed so much, but for the Linux kernel even more so.
 
arp242 said:
In general using CVEs to track "security issues" is very flawed
Click to expand...
If you only look at any CVE, yes. But one CVE is not like the other, there's a certain amount of risk involved, or not. Or how easily it's exploited, or not. If there's active exploits in the wild, or not. If it can be remotely done, or not. Etc. Just looking at the absolute number of CVEs is pretty much useless from a security standpoint.

I have to deal with a shitty security scanner every week. Most of the "critical" or "high" security issues are non-issues for us, because they often deal with bugs in drivers we don't use. But hey, that driver is baked in the kernel, so the scanner throws a fit and by extension the CISO does too.
 
Crivens said:
Maybe that is when people started using LLMs to generate code?
Click to expand...
To be clear, i don't think every use of AI was intentional. Maybe you ask a question on stack overflow, and some helpful guy asks some LLM for an answer and you take that then as a third party without doing anything on your own. We would need numbers for lines of code per month from humans, worldwide, and LLMs, worldwide. Then we may see an uptake and see if it correlates. Not that that would prove anything...
 
msplsh said:
Downplaying "useless" CVS like nobody's ever heard of exploit chaining
Click to expand...
No, CVE-2026-80591 is just a different kind of risk than CVE-2026-31431 ("copy fail") is. The later is way, way more dangerous. Lumping them together as if they are equal is just plain stupid.
 
cracauer@ said:
This is highly relevant to FreeBSD.

It is unlikely that the number of bugs per line is significantly different between Linux and FreeBSD's kernel.
Click to expand...
Is this speculation or is there is any believable data point for this? BSD should strive to do better regardless of what Linux does. Though I suspect they are going in the same direction....
 
bakul said:
Is this speculation or is there is any believable data point for this? BSD should strive to do better regardless of what Linux does. Though I suspect they are going in the same direction....
Click to expand...

From my experience similar software in similar programming languages has about the same amount of bugs, unless temporarily lowered by a deliberate bug hunt (while stopping addition of new code).
 
I would like to see a graph of the current tools run against 6.9 to 6.19. I think it would give a better picture of the base number
 
Interesting discussion about the cost of a CVE. Highly relevant to this discussion. From the curl team.

daniel.haxx.se

a CVE dispute

A few years years ago the curl project signed up and became a CNA. This means that we are masters of and can allocate our own CVE identifiers. For any security problems within our territory, it is we who decides if the issue should get a CVE or not. No more bogus CVEs. 57 CVEs … Continue reading...
daniel.haxx.se daniel.haxx.se

And the hackernews followup:

A CVE Dispute | Hacker News

news.ycombinator.com news.ycombinator.com
 
Seems like pointless non data to me.

Clickbait "News"...

As they have been introducing more and more code from corporate contributors, who in turn have most likely been using LLMs, then using LLMs to find bugs and CVEs in that same code isn't really anything to shout about. In the absence of any data, they could be introducing many bugs every release, as part of the "fixes" to the previous releases bugs...

"2000 CVEs" is meaningless, all would need to be scrutinised. "LLM finds 20 year old bug" type headlines is "news"...
 
arp242 said:
The Linux kernel has a very liberal interpertation of what should be a CVE: "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"
Click to expand...

and I have a very conservative interpretation of what constitutes the kernel. I would not count any runtime loadable device drivers in that 40million line code count. device drivers would, in my book, be counted as separate entities. In my world the kernel is scheduling, memory management, and OS primitives: things that are compiled into one required blob.
 
Forget about Linux for a moment. I think it would be more productive for us to learn how to port software, maintain ports, and perhaps eventually contribute code to BSD itself. One thing I like about the BSD model is the relatively clear division of responsibility for the base system, kernel, security maintenance, and ports. Linux distributions have a different model: they integrate the Linux kernel with software from many independent upstream projects, and each distribution may carry different versions, patches, configurations, and backports. Linux distributions are already showing their own problems, especially with package ecosystems such as Nix, Pacman, and the AUR. This also makes raw CVE counts difficult to compare. The same CVE may have a very different impact on Debian, Fedora, Arch, etc., while each distribution may publish its own advisory for the same underlying vulnerability.
 
You must log in or register to reply here.
Back
Top