this post was submitted on 31 Oct 2026
212 points (94.5% liked)

Linux

68709 readers
975 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 7 years ago
MODERATORS
nooter692@lemmy.ml
AgreeableLandscape@lemmy.ml
MarcellusDrum@lemmy.ml
cypherpunks@lemmy.ml
cyclohexane@lemmy.ml
d3Xt3r@lemmy.nz
212
Linux security vulnerabilities fixed per kernel version (lemmy.ml)
submitted 1 week ago by MarcellusDrum@lemmy.ml to c/linux@lemmy.ml
91 comments fedilink hide all child comments
 

Something good coming out of AI, it seems.

top 50 comments
sorted by: hot top controversial new old
[–] non_burglar@lemmy.world 40 points 1 week ago* (last edited 1 week ago) (6 children)

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.

[–] Link@rentadrunk.org 24 points 1 week ago (2 children)

I thought Torvalds said major versions bumps were meaningless so 6.0 or 7.0 is the same as 6.12 to 6.13

[–] non_burglar@lemmy.world 13 points 1 week ago (1 children)

Minor versions go up according to a certain pattern based on how the change mgmt is handled for the kernel, but major releases are marked when the kernel team "feels it's the right time".

From lwn: https://lwn.net/Articles/871989/

To kernel developers, version numbers continued to have no meaning other than as a measure of where things were on the timeline, he said; users were encouraged to run the latest version. But if you tell customers they need to move from 3.20 to 4.0, they will consider it a multi-year effort that requires planning and paperwork; "so they will only do it when they have time, which is never". Going from 3.20 to 4.0 seems like a big jump, and 4.0 to 4.2 seems much smaller, even though the latter brings roughly double the number of changes.

[–] kieron115@startrek.website 11 points 1 week ago (2 children)

Maybe in the past, but that doesn't seem to be the case at the moment.

Torvalds pointed out that the numbers he applies to new kernel releases are essentially meaningless.

“We haven't done releases based on features (or on "stable vs unstable") for a long, long time now. So that new major number does not mean that we have some big new exciting feature, or that we're somehow leaving old interfaces behind. It's the usual "solid progress" marker, nothing more.”

[–] non_burglar@lemmy.world 4 points 1 week ago

Thanks for this, I think I now understand what others are sating about this.

load more comments (1 replies)
[–] thingsiplay@lemmy.ml 12 points 1 week ago* (last edited 1 week ago) (3 children)

The version numbers are not really meaningless, because anything higher than .20 is life-threatening to Torvalds. But technically and functionally, it doesn't matter.

[–] kieron115@startrek.website 10 points 1 week ago

Lol he said he doesn't want any version number higher than what he can count on his fingers and toes.

[–] Edie@lemmy.ml 9 points 1 week ago (3 children)

What does he do when he gets to 19.19?

[–] thingsiplay@lemmy.ml 9 points 1 week ago

I hope he is still around at that time.

load more comments (1 replies)
[–] laurelraven@lemmy.zip 3 points 1 week ago

I think he just doesn't want to wind up stuck again like with 2.6, which was the mainline kernel version from 2003 through 2011, finally ditching their classic semantic versioning and bumping to 3.0 from 2.6.39 in July 2011

[–] PattyMcB@lemmy.world 9 points 1 week ago

I'd love to see the graph include data back to 4.x.

"Axis bias" is real

[–] thingsiplay@lemmy.ml 6 points 1 week ago (2 children)

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.

[–] non_burglar@lemmy.world 6 points 1 week ago (2 children)

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.

[–] thingsiplay@lemmy.ml 3 points 1 week ago* (last edited 1 week ago) (3 children)

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.

[–] non_burglar@lemmy.world 4 points 1 week ago (7 children)

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.

load more comments (7 replies)
load more comments (2 replies)
[–] laurelraven@lemmy.zip 2 points 1 week ago (1 children)

As others have mentioned, 5.0 and 6.0 and 7.0 are really just version bumps the same as any other with no extra meaning beyond "we got tired of being stuck on 2.6 for 8 years and decided we're not doing that anymore".

It's not using semantic versioning and hasn't since 2011... Realistically, it hasn't since 2003 seeing as they spent 8 years without any single release being "big enough" to bump even the minor version number, let alone the major. Honestly, if they were still using that criteria from the pre-3.0 era, we'd probably be on something like 2.6.100 right now

load more comments (1 replies)
[–] senslayer@lemmy.ml 3 points 1 week ago (1 children)

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

[–] thingsiplay@lemmy.ml 4 points 1 week ago

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.

[–] atzanteol@sh.itjust.works 5 points 1 week ago (2 children)

How is it misleading? All you've said is that releases have cves which is what the graph shows.

[–] non_burglar@lemmy.world 7 points 1 week ago (6 children)

As I mentioned, all kernel major releases have cve bumps, because (also mentioned) new kernel releases have new features and drivers.

The bump itself doesn't show that ai is associated with more CVEs, because that bump is present after every kernel major release. It would have been better to show the bumps from previous releases to demonstrate the volume ai tools are helping to find.

[–] fleinsopp@lemmy.ml 6 points 1 week ago (1 children)

That's not how the version numbers for the Linux kernel work. 7.0 is the release that follows 6.19, they are both new mainline releases in the exact same way, and the first number increasing doesn't mean anything.

load more comments (1 replies)
load more comments (5 replies)
load more comments (1 replies)
[–] Static_Rocket@lemmy.world 4 points 1 week ago

Yeah, wasn't the security community just complaining about the number of CVEs published recently which were just unfiltered bug reports?

[–] dusk@piefed.social 31 points 1 week ago (1 children)

oh wow fam, ai is protecting us from... ai

[–] MarcellusDrum@lemmy.ml 20 points 1 week ago (1 children)

Or from NSA backdoors.

[–] Clark@lemmy.ml 3 points 1 week ago

Why not both?

[–] MonkderVierte@lemmy.zip 30 points 1 week ago (2 children)

How many of them are new?

[–] pineapple@lemmy.ml 9 points 1 week ago

Most likely very few of them because the code still gets reviewed by humans.

[–] shirro@aussie.zone 22 points 1 week ago* (last edited 1 week ago)

The Linux kernel team has a policy that all bugs are potential security threats and should be assigned a CVE. That does not mean these CVEs are exploitable. Many will be for features that aren't even enabled on typical systems.

LLMs are allowing researchers to locate known classes of bugs more easily than an exhaustive search with other tools. Security researchers are driving the bus here. Not the tech companies or their products. Don't believe the marketing hype. The tech companies want us to be dependent on subscriptions to their products and deskilling is part of their agenda. Good stuff is coming from security researchers using expertise and tooling.

[–] pineapple@lemmy.ml 18 points 1 week ago (2 children)

People here can't seam to get past there built in kneejerk reaction to anything AI related.

[–] kadu@scribe.disroot.org 19 points 1 week ago (21 children)

get past there built in kneejerk reaction to anything AI related

Maybe because it's not kneejerk. We know how AI works, what it takes to have it running, how it was built, who controls it. For many people, the ends do not justify the means (and that's if we assume fixing CVEs on Linux is somehow worth the very problematic ends AI is leading us towards anyway).

load more comments (21 replies)
[–] corsicanguppy@lemmy.ca 4 points 1 week ago

there built in kneejerk

WHERE built in the kneejerk?

[–] corsicanguppy@lemmy.ca 15 points 1 week ago

Potential Linux security vulnerabilities.

[–] beejjorgensen@lemmy.sdf.org 7 points 1 week ago

The more fixed, the better.

[–] the_abecedarian@piefed.social 6 points 1 week ago (3 children)

how many are introduced by new ai code?

[–] yogthos@lemmy.ml 41 points 1 week ago* (last edited 1 week ago) (2 children)

Assuming that Linux kernel team continues to use the same review process they always had, there's zero reason to think that there would be an increased rates of bugs due to LLM generated code. This seems to be something people without programming experience don't understand. Code quality isn't premised on trust, it's a product of the development process. Projects ensure quality by having specifications, tests, doing code reviews, and so on. As long as the practices the kernel team has established continue to be applied, they will catch the bugs made by LLMs or humans exactly the same way.

[–] python@lemmy.world 14 points 1 week ago (1 children)

Idk man. I've certainly become more lenient in Code Reviews because I have to do like 5 a day instead of 2-3 a week, all with like 2k lines of changes. I literally don't have the time to fully read tests anymore, I mostly just skim them and check whether they have an assess statement that looks somewhat reasonable.

Hell, I've recently had a meatpuppet of a coworker brag about how his implementation of a Card component for the UI library had 199 tests. I'm so glad I wasn't assigned to review that shit. But it sure looks great to the higher-ups 🫠

Hopefully working on the Linux Kernel doesn't suck as much as working for a big corp.

[–] yogthos@lemmy.ml 9 points 1 week ago

Large corps always end up implementing shitty practices because business practices are driven by pencil pushers. Even before LLMs, some of the most soul crushing jobs were found at large corps working with shit like J2EE. That's nothing new really.

At my job, we use LLMs, but nobody is making 2k loc PRs all of a sudden, and we still pair up to review code, and generally work at human speed.

[–] HopeOfTheGunblade@lemmy.blahaj.zone 3 points 1 week ago (1 children)

As long as the practices the kernel team has established continue to be applied,

Right, the question is, if they're changing the writing code practices, do you think there might be any change in the reviewing process?

[–] yogthos@lemmy.ml 7 points 1 week ago (1 children)

I've seen no evidence of that so far. I also fail to see how writing code practices are related to the review and quality control process. These things aren't linked in any way that I'm aware of.

[–] HopeOfTheGunblade@lemmy.blahaj.zone 5 points 1 week ago (1 children)

The ability to comprehend code underlies both of those and is trained by both. Doing less of one reduces your training.

LLM use leads to skill deficits, it's shown up in studies but also just, use it or lose it.

[–] yogthos@lemmy.ml 7 points 1 week ago* (last edited 1 week ago)

The only studies I'm aware of used tiny samples and produced muddled conclusions. If you have some conclusive empirical research then do feel free to share it though. Meanwhile, using LLMs doesn't mean doing less, it just means focusing on different things. The skill deficit here is the same kind as the skill deficit people have using punch cards or writing assembly by hand today. As more aspects of coding become automated, different things become relevant and that's what people shift their attention to.

[–] oinari@piefed.zip 3 points 1 week ago

Not sure about AI specifically, but the number of new bugs seems to be going down in new releases:

See: https://lwn.net/Articles/1088776/

load more comments (1 replies)
load more comments
view more: next ›