Something good coming out of AI, it seems.
Your dialectic skills truly know no bounds.Edit: I responded to the wrong person.
Potential Linux security vulnerabilities.
This is misleading.
Edit: “misleading” was the wrong word. I was just pointing out that showing data from 4.x to 5.x, 5.x to 6.x also would have made this post more meaningful.
Linux kernel full releases always have CVEs shortly after them because new features, drivers, memory handling tuning, and other capabilities arr introduced, and people (or ai) hammer away at them as soon as they appear.
I acknowledge that the bump has more amplitude because ai tools accelerate this, but this graph isn’t the shocker you think it is.
I’d love to see the graph include data back to 4.x.
“Axis bias” is real
This is misleading.
Is it? What exactly is it misleading here? It just aligns with the usage of Ai, which means that Ai tools helped finding and fixing those issues. I don’t see anything misleading.
The meaningful data would have been to show the amplitude of the commit frequency bump compared to 5.0 and 6.0 releases, because, as I mentioned, they have bumps just after release also.
This just shows a bump after a release, which doesn’t really show “AI” anything.
It shows that the CVE fixes were consistent during the last 2.5 years and 14 releases. And with the recent rise of Ai usage in the Kernel, this bump aligns.
commit frequency bump compared to 5.0 and 6.0 releases
Why 5.0 and 6.0, those are ancient. This goes back to 6.9 from May 2024, where Ai usage in the Kernel wasn’t a thing until the recent few releases.
It shows that the CVE fixes were consistent during the last 2.5 years and 14 releases.
Right, yes. But if the transitions from 4.x to 5.0 and 5.x to 6.0 were also shown, we’d be able to see that the bump itself isn’t significant, and that this happens after every major version release.
The magnitude of the bump is what’s important, and we can’t see that without comparing to pre- and post- AI tooling.
Why 5.0 and 6.0, those are ancient. This goes back to 6.9 from May 2024, where Ai usage in the Kernel wasn’t a thing until the recent few releases.
That’s the whole point.
There is no need to go older. We have 14 releases in between 6.9 and 7.2.
I don’t understand what you’re saying… Those aren’t major releases, those are dot releases, and they cross a major release.
Linux versioning does not work like that. There is no major release, the are all equivalent. It’s not a joke, Linus Torvalds just don’t want high numbers, so at the latest .20 (dot-twenty) release they create a new major one. But functionally it doesn’t matter. Therefore the release version is meaningless for our discussion. I’m really serious about this, this is not in any way trolling or being toxic. All we need for this discussion are already present in the graph.
Have a look at: https://en.wikipedia.org/wiki/Linux_kernel_version_history
In contrast to semantic versioning, the major version carries no intrinsic meaning for the kernel, as Linux promises stable interfaces and behavior even when the major version changes. However, since version 3.x, minor versions have been capped around 20 to avoid the false perception that changes between large minor versions (e.g. from 5.30 to 5.31) would be less voluminous or impactful than changes between smaller minor versions (e.g. from 6.1 to 6.2).
It’s not AI usage in the kernel - it’s the increase in AI to do code auditing that had seen the spike in bug reports. A lot of FLOSS projects are seeing this regardless of their use of not of AI to generate code.
It’s not AI usage in the kernel - it’s the increase in AI to do code auditing that had seen the spike in bug reports.
Umm, that is Ai usage in the Kernel. I didn’t talk about generating code. The developers use Ai. You even explain how they use Ai…
The graph would’ve been stronger if other versions were included. Something like this is for example, (it’s lowk a bad example though since i can’t really tell much about what the author is claiming as an effect of the figure)
https://www.blogspan.net/linux-kernel-cve-2026-98432-tcp-ubuntu-fix/
Which shows compared to previous years a similarish rise in cves but they appear more trivial (for a variety of reasons such as enhancing requitements to be high risk cve)? Would be worth replication
The graph would’ve been stronger if other versions were included.
It shows versions up to v6.9 from May 2024, which is a span of 2.5 years approx. and 14 releases. And with the knowledge that Ai usage accelerated during the last few releases, we can conclude its a major factor here for the rise.
Yeah, wasn’t the security community just complaining about the number of CVEs published recently which were just unfiltered bug reports?
People here can’t seam to get past there built in kneejerk reaction to anything AI related.
there built in kneejerk
WHERE built in the kneejerk?
Just like most technologies, they aren’t all bad or all good. In this case it’s been good.
