The Linux Kernel Is Approaching 2,000 CVEs Per Release

Phoronix reports on Greg Kroah-Hartman's recent slide from his upcoming talk in Paris at Kernel Recipes 2026 (September 21 to 23): 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... Fortunately, most often they end up being lower priority vulnerabilities and often within old/obscure driver code, so the impact is often minimal.

It seems that AIs have great eyeballs

[Alain Williams]

To work Linus' Law [wikipedia.org] needs many eyeballs, unfortunately these are not always around. It seems that AI is helping - which is good. I assume/hope that the current deluge will abate once the current/historic CVEs get fixed and that the only new ones are for bugs in new code.

Re:

[sound+vision]

It sounds like it finds the most bugs in code with the least human attention given to it (old drivers, etc.) In other words, it gets the low-hanging fruit.

So it's better than nothing, but not as good as human review. It could have a place in the security ecosystem. Will it come at the expense of human reviewers, though? Because then it's a net negative.

Re:

[gweihir]

Exactly. It also needs to be done as the attackers will do it as well. But in a while this effect will die down and we are back to humans doing the vast majority of problem finding.

Re:

[gweihir]

Not really. LLMs are actually pretty crap at this. But they have a somewhat different perspective than humans and are not prone to boredom. So they find bugs now that humans did not find, but that is a pretty temporary effect.

This is the correct use for AI

[Valgrus Thunderaxe]

vs. weaponizing it to spy on people.

Worth keeping in mind

[sjames]

Many CVE's are somewhat junk of the form if you already have 3 ways to legitimately become root, you can use this 4th way too. OR (samn close to) OMG!!! Denial of Service attack, you can turn off the power and nobody can access the server!!! RED ALERT!!!

Others are real and need to be addressed, but the junk does more harm than good by distracting from real issues.

Re:

[LainTouko]

The thing is, Linux is a general purpose kernel rather than something only ever used to run servers with, so the kernel folks can't predict everyone's security model and so have to report anything which allows more to be done with any set of privileges than should be possible, whatever it is. What's really needed here is a secondary classification stage, something like a project which makes a set of assumptions about the security model which are true in most servers and you can check are true for your serve

Re:Open source was supposed to fix all this

[sjames]

Closed source has those vulnerabilities too, but only the bad guys know about them because the code is not open for public audit.

Re:

[davidwr]

but only the bad guys know about them because the code is not open for public audit

The developers may know about them but don't have the resources to fix ALL of the known bugs.

More likely, the developers are careful not to go on an internal "bug hunt" that will find bugs faster than they can fix, because someone out there will be "injured" by the one bug they prioritized as "fix later" and sue. "Because lawyers."

Re:

[sinkskinkshrieks]

FOSS isn't the panacea evangelists claim it is. What's desperately missing in Linux and most projects is formal verification and comprehensive testing. It's half-assed, meatcloud-based, "works for me" as the default while brushing engineering professionalism aside with "it's a volunteer effort and a hobby" when it's become life-safety critical infrastructure.

Re:

[PPH]

Whereas my Aunt Millie is a beta tester for Windows releases.

Re:

[davidwr]

Whereas my Aunt Millie is a beta tester for Windows releases.

Interestingly, just this week a major American fast food chain is offering a "be a beta tester for our app and get a discount on your next order" promotion.

Re:

[PPH]

a major American fast food chain

"I'm sorry sir. You say you did _NOT_ order the rat poison topping for your salad? Your next order will be on us. If you survive."

Re:

[WaffleMonster]

FOSS isn't the panacea evangelists claim it is. What's desperately missing in Linux and most projects is formal verification and comprehensive testing.

Formal verification of a general purpose monolithic kernel is a fools errand. There are a number of formally verified kernels to pick from including FOSS kernels. It's just a matter of picking the right tool for the job.

Re:

[davidwr]

formal verification and comprehensive testing

Comprehensive testing is expensive.

Formal verification is also very difficult, but at least one formally verified microkernel, SeL4 [wikipedia.org], is in production. Having a formally verified microkernel is NOT the same as having a formally verified computing environment.

Re:Open source was supposed to fix all this

[UnknowingFool]

Open sourcing your code, and relying on it, is more of a risk to orgs now that AI can actually analyze it and find 20 year old vulnerabilities no one saw.

As opposed to closed source where no one will ever know that a 20 year vulnerability is being exploited by unless the company acknowledges it (if that company is till around).

Re:

[allo]

I don't see the issue. Users found a lot of bugs that are NOT in the code anymore and AI now finds a lot of bugs that users didn't see.
You just don't know how Windows' source code looks like and how many bugs are hiding in there.

Re:

[paulpach]

The argument was "Given enough eyeballs, all bugs are shallow". However some studies [acm.org] suggest there is no significant difference between OSS and closed source when it comes to security.

But not all is lost, there are 2 recent developments that change the game:
* AI is fantastic at finding bugs, as this article points out, we are starting to see an avalanche of patches from AI found vulnerabilities. I expect we will have more robust and safer software in a year or two when the tsunami is behind us.
* New memory

Should decline

[SuperDre]

To me it sounds problematic if each release has even more CVEs found by AI fixed, as you should think that after a few releases that number should decline instead of increase as most CVE's should be fixed by then and only a very few new CVE's should be found (like ways never thought off, so nobody looked for those).

For how long?

[allo]

Given that all new patches are probably checked soon after they are pushed, there will be a day when most older bugs are found. Then the number will go down again, and this will be a good sign.

Design choices

[backslashdot]

Whew thank God Linux is a monolithic kernel with a minimal attack surface and no drivers up the wazoo to worry about.

Re:

[davidwr]

Whew thank God Linux is a monolithic kernel with a minimal attack surface and no drivers up the wazoo to worry about.

There are ways to do just that. Minimal drivers, all compiled in. No loadable modules. Secure/trusted boot environment. Minimal access to I/O with strong input sanitization and very likely a read-only filesystem so a reboot is a true fresh start. This won't be your general-purpose computer though.

Open advantage

[Going_Digital]

So open source like Linux will gradually become more secure, whereas closed source will never get fixed.

This will fall off again in a while

[gweihir]

The LLMs currently find all the boring bugs nobody was interested in finding. Once these are gone, we will be back to normal.