[Discuss] With AI, 2, 000 Vulnerabilities per Linux kernel release

[rrose at pobox.com (Randall Rose)]

On Fri, Sep 4, 2026, at 7:18 PM, Rich Pieri wrote:
> On Fri, 04 Sep 2026 14:29:10 -0400
> "Randall Rose" <rrose at pobox.com> wrote:
>
>> Yes, it's in the "certainty unless" category.  Identifying something
>> as being in the "certainty unless" category doesn't tell you much
>> either way.
>
> "Luckily the Linux kernel is not one of those cases."
>
> -- 

The reasoning contained in that sentence is inconclusive, which is what I've 
been saying in my past responses too.

I guess what I'm taking away from this is:
--Possibly there is some risk to the Linux kernel's viability, if the number 
of AI-detected CVEs continues to increase and either adversaries have access 
to better AI than kernel developers do or the rate of kernel developers' 
detection of CVEs by using public AI and other means outstrips kernel 
developers' capacity to fix them.
--Neither "there will be an apocalypse" nor "there won't be an apocalypse" is 
certain at this point. A risk entails lack of certainty which should be 
recognized.  Not all uncertainty is adversary-created FUD.
--Current kernel developers, or at least some of them, perceive a significant 
risk here.  I already quoted a kernel developer's pull request "If we want to 
have a fighting chance of surviving the LLM-pocalypse", so they genuinely see 
viability risk here.  It isn't just one kernel developer who's concerned 
about this; the risk is already great enough that it has led to Linus 
Torvalds pulling support for less new hardware sooner than kernel people 
would otherwise have wanted.
--Losing support for drivers or even other features (because they are too 
time-costly for developers to maintain in the face of increasing AI-detected 
CVEs) is a more immediate problem than loss of overall viability for Linux, 
but the latter can't be ruled out.  
--This is not simply a problem of software that is so badly coded that it's 
more efficient to start over.  Kernel developers' main concern seems to be 
with kernel software that was written with a more typical level of skill, 
which nevertheless is facing an increasing rate of known CVEs.
--It has become clear that claims made in the past about Linux not facing 
significant hacking threats are not true.  In the contemporary world, all 
systems face significant hacking threats and Linux is no exception.  The 
ability of current AI to search somewhat more thoroughly for vulnerabilities 
has revealed that the number of findable CVEs in the Linux kernel that are 
worth fixing is much larger than what some Linux users would have tended to 
assume.
--With a rate of 1900 CVEs fixed in the two-month period between the two most 
recent kernel versions, it is clear that, now and in the near future, 
adversaries will have zero-day access to some CVEs before kernel developers 
know about them. That is statistically inevitable when there are 1900 CVEs, 
and more so if the number increases above 1900 and/or adversaries have better 
AI.  The same goes for other OSes, of course.
--The danger to Linux is not necessarily imminent (and even if it did come to 
pass, it would not destroy the overall aim of FOSS).  A more forward-looking 
approach might focus on doing early work towards a formally-verified 
open-source OS in a language that is easier to use safely (such as Rust).