AI Finds So Many Linux Bugs, Canonical Changes to a Two-Week Stable Release Update Cycle (nerds.xyz)
- Reference: 0185866632
- News link: https://news.slashdot.org/story/26/09/26/0559227/ai-finds-so-many-linux-bugs-canonical-changes-to-a-two-week-stable-release-update-cycle
- Source link: https://nerds.xyz/2026/09/ubuntu-linux-ai-security-fixes/
AI has transformed bug discovery from "a manual, time-intensive process into a highly automated engine," notes Canonical's blog, leading to [2]a "recent explosion in the volume of CVEs ".
> Additionally, the upstream kernel community became its own CVE Numbering Authority (CNA) and assigned CVE (Common Vulnerabilities and Exposures) identifiers to thousands of bugs, arguing that at the kernel level, almost any type of bug that can affect a running system, could potentially be classified as a vulnerability. As a result, the volume of CVEs has skyrocketed exponentially, creating a massive backlog of alerts and forcing defenders to drastically increase the speed of their fixes to close the window of risk.
>
> To address the growing volume of CVEs and the demand for faster security fixes, we are transitioning to a unified, 2-week release cycle...
>
> While a patch is being prepared, Canonical aims to provide safe workarounds where applicable, so users aren't left exposed in the meantime. Where no safe workaround exists, Canonical will say so clearly and point users toward general hardening steps instead. The goal is to get environments into a defensible, safer state within 24 to 48 hours of public disclosure — well before a patch ships. This doesn't replace the patch; it buys the time needed to fix the vulnerability properly, without sacrificing security.
"Linux did not suddenly become wildly insecure overnight," [3]notes the blog Nerds.xyz . "We are getting much better at finding and cataloging problems that may have previously gone unnoticed."
> There is something almost ironic about all of this. AI is routinely pitched as a tool that will make software development faster, but it is also making vulnerability discovery faster. That means maintainers now have to accelerate the other side of the equation too.
>
> For Ubuntu users, that should ultimately be good news. More bugs being discovered is preferable to vulnerabilities sitting unnoticed in the Linux kernel.
[1] https://www.slashdot.org/~BrianFagioli
[2] https://canonical.com/blog/accelerating-delivery-of-cve-fixes-with-a-new-kernel-release-strategy
[3] https://nerds.xyz/2026/09/ubuntu-linux-ai-security-fixes/
what kind of bugs (Score:4, Interesting)
How many are realisically actionable vulnerabilities. The statistics have indicated so far that AI isn't really finding many non-minor bugs.
Re:what kind of bugs (Score:5, Insightful)
From other projects, I see about a third or half of bugs the AI finds are legit. Most of those are small corner cases or error handling issues that almost never trigger, but most are actionable. But I value even a 1 line change that clears a static analysis warning if even in practice it was impossible to trigger the issue in a real system.
Re: what kind of bugs (Score:2)
i can understand that, so it's more of a source code cleanup.
Re: (Score:3)
> But I value even a 1 line change that clears a static analysis warning if even in practice it was impossible to trigger the issue in a real system.
Yes, I agree. The problem with thinking "this bug seems harmless, because I can't imagine how anyone could exploit it" is in the "I can't imagine" part; my imagination is limited to what is covered by my mental model of how computers work, but an attackers' ingenuity is not.
In particular, the C/C++ optimizer is a devious beast, and will exploit any opportunity to make the code more efficient, even if that means doing things that are wildly unintuitive to a naive human reader -- and it sees any instance of
Re: (Score:1)
I think the thing is it doesn't really improve the software all that much. It's literally bugs that are there because nobody has bothered looking for them.
So it's basically generating a shitload of work fixing and testing bugs that probably weren't worth fixing. You're seeing the same thing in mathematics where AI will solve some 300-year-old math problem you get a bunch of headlines and then you read and find out the reason it's been unsolved for 300 years is because nobody bothered and it wasn't all t
Re: (Score:2)
This argument makes zero sense.
First, people are asking what the number is, they already know that it's being used to justify a two week release schedule.
Second, I think most people here would like to know what on earth a volume of unknown bugs has to do with a two week release schedule. That's not how bug fixes works.
- If bugs are causing problems NOW for people and/or are security issues, you release ASAP, you don't want for a rolling release.
- If bugs are not causing problems now, you provide testers wit
Re: (Score:2)
> How many are realisically actionable vulnerabilities. The statistics have indicated so far that AI isn't really finding many non-minor bugs.
Seems to be a bit of selection bias baked into what AI is being asked to do. Tried AI (GLM-5.3) on new code that has never been executed. Also ran it against code that has been in production use for many years.
The types of bugs tended to be in obscure features, buggy error paths, parsing / protocol pedantry, cut and paste errors especially in various lookup tables, algorithm accuracy, inconsistencies, poor and obscure concurrency bugs. Can't really expect it to have found anything too important as it woul
Re: (Score:2)
Yeah, the curl devs (to name one project I monitor) are still having to swat away the vast majority of bug reports from what I've seen even if they're being far more positive about slopreports than I would be.
I'm also interested in how many bugs are being added en-mass by people trying to fix minor issues an LLM identified.
Re: what kind of bugs (Score:2)
these aren't even bugs. these are rough spots that remained because it wasn't worth the effort. Now AI is just filling in for the human doing it.
Re: (Score:3)
If you're running Debian, there's no benefit to you, because Debian is getting the same warnings, and responding just as fast (or faster).
OTOH, I don't have the version name memorized. I think Trixie is the current one, so that just means be sure to run apt update frequently. (I do it nearly every night.)
Re: (Score:2)
OK. I don't have those, so I don't know about that.
I mainly don't do auto-update because ... well, because I stopped doing it years ago, I forget why, and doing the update is no hassle.
Re: (Score:2)
In general, all code is always pushed upstream, barring legal reasons. Because by pushing it upstream you also push maintenance costs upstream; by not pushing upstream, you set yourself up to forever maintain a fork and to forever merge your changes again and again into a forever changing and diverging upstream code base. Which is a drag.
Just one day (Score:2)
I'd like to go one day, just one day, without seeing an AI story. Christ!
Re: (Score:3)
For that, I think you'll need a time machine to take you back to well before the 2020's.
Re:Just one day (Score:5, Funny)
> I'd like to go one day, just one day, without seeing an AI story. Christ!
I am truly sorry my son, but I can do nothing about this. I am the ALmighty not the AImighty.
Re: (Score:2)
Stop reading tech news?
It got rusty. (Score:2)
/* klibc was better */
Total coverage. (Score:2)
A thousand AI eyes makes bugs shallow.
Ultimately is this not all to the good ? (Score:2)
Bugs (in new code) are hopefully being added more slowly than bugs found and squashed in existing code - so surely the number of remaining bugs will drop. Hopefully those running bug finding AIs are not keeping some remote exploitable bugs to themselves; I would not be surprised if government agencies were doing this.
Re: (Score:2)
You left out the category of new bugs created by the patches and "upgrades", especially for new features.
Which somehow made me think of an even worse race condition, though I'm not sure how to describe the level of abstraction here... If the AI search for bugs goes to a certain depth, and assuming there are no bugs in the search algorithms, then what happens when the AI gets a bit smarter and searches a bit more deeply?
Long time ago when I was first studying computer security, but I remember two fundamental
Re: (Score:2)
Government agencies have been caught red-handed weaponizing critical vulnerabilities and keeping that to themselves. Criminals managed to hack some and sell the vulnerabilities off on the black market, forcing disclosure for remediation.
Re: (Score:1)
Is it known ( in theory ) whether all "bugs" can be identified BEFORE working code is completed ? Trivial typos excepted, I would guess not. Kinda like throwing rocks off a cliff ... whether that's a "buggy" behavior depends on what/who sits below the cliff.
Unbalancing the arms race? (Score:4, Interesting)
> AI is routinely pitched as a tool that will make software development faster, but it is also making vulnerability discovery faster.
That was my first thought and I'm glad the story mentioned it. But I'm concerned that AI may tilt the table in favour of bad actors. Mightn't it lower the bar when it comes to expertise at finding and exploiting vulnerabilities, while simultaneously increasing the burden on already over-worked programmers?
In other words, does AI help black-hat hacking organizations more than it helps good-guy programmers and maintainers? I'm thinking of how a hammer is more easily used to destroy than to create, but IANAP so I don't have a good sense of this.
Re: (Score:2)
In the short term. Right now the bad guys (well, non-state bad guys) don't have access to frontier models with the cyber security nanny mode disabled. However open source models are getting better every day and most don't have those guardrails, and even if they do it's not impossible to remove them when you have access to the weights. So yea, short term it's going to be an issue.
Long term, however, once this initial tsunami is worked through then hopefully more of these types of bugs will be found before
Re: (Score:2)
That will only be true if "good-guy" programmers decide against using tools that can help them address problems as fast as or faster than the bad guys can find them.
Re: (Score:2)
> That was my first thought and I'm glad the story mentioned it. But I'm concerned that AI may tilt the table in favour of bad actors. Mightn't it lower the bar when it comes to expertise at finding and exploiting vulnerabilities, while simultaneously increasing the burden on already over-worked programmers?
> In other words, does AI help black-hat hacking organizations more than it helps good-guy programmers and maintainers? I'm thinking of how a hammer is more easily used to destroy than to create, but IANAP so I don't have a good sense of this.
Bouncing code off of AI is being baked into software lifecycles and will result in fewer bugs across the board. For open source you will have more people armed with AI finding even more bugs (while annoying the shit out of maintainers). The interesting thing about these models you can run them over and over and over again and sometimes different bugs fall out so the more AI eyeballs the better. Still I expect ultimately the computational cost of finding any remaining bugs to work against attackers.
On the
If canonical is so worried (Score:2)
about the volume of work, they should be using LTS or SLTS kernels, instead of bespoke Kernels. For instance, Ubuntu 26.04 LTS uses kernel 7.0 (not LTS, and certainly not SLTS), which means canonical engineers have to do all the backporting and patching work...
Anywho. Good luck to canonical and their users.
Re: (Score:1)
As someone who lives in the world of enterprise Linux distributions there's a couple of reasons for this.
One, the release timeline and lifecycle of a particular LTS distro like Ubuntu or RHEL pretty much never lines up with that of the upstream kernel maintainers. With an ELS add-on, you can get about 15 years of critical CVE support for RHEL. Upstream will have moved on a long time before that.
Two, these distros do their own QA and release management. A bug that they have reported will almost always get pa
Re: (Score:2)
Whether or not one lives in the enterprise kernel world (I do as well), a glance at the mainstream kernel's changelog indicates we're all largely relying on those companies' employees. Most patches are coming from people who are paid by Red Hat et. al.
Great! (Score:5, Funny)
Great, now do windows 11...
Re:Great! (Score:5, Funny)
There aren't enough tokens in the world....
Re:Great! (Score:4, Funny)
I turned claude on windows 11. After running for a few weeks, it generated the final result. It turned out to be Linux.
Re: (Score:2)
Hilariously Microsoft is trying. I'm slightly interested to see if anything comes out of it but I'm not expecting much.
The real problem with Windows 11 is every single division in Microsoft is required to be profitable because of course they are so you're fucking weather app uses 3 GB of RAM so it can serve up a limitless supply of advertisements in an effort to make money off a freaking weather app...
All those divisions aren't going to give up their RAM and resources without a fight. So I don't see
Not quite (Score:1)
I promise you that the weather app is not it's own division with a P&L statement at Microsoft. Instead, you have Experiences + Devices (which has a P&L) and under that, Windows + Devices (which has a P&L). I left MSFT several years ago so I don't know the org chart under W+D or whether there are P&Ls under that level. Typically the CVP (corporate vice president) and up at MSFT has a P&L.
Anyway point being that someone is absolutely putting ads in the weather app to meet his P&L obje
Re: (Score:2)
Given the number of updates in the last few months, I'd say they already have.
Re: (Score:2)
They have, that's why Microsoft has been releasing so many patches lately.
Remember all the comments about how incompetent Microsoft developers are, and how Linux is so much better? Turns out nobody is safe from AI bug hunters.
For me it's more of a pain with Linux because now I have to support a whole Linux SBOM.