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.
 
You must log in or register to reply here.
Back
Top