190
Linux security vulnerabilities fixed per kernel version (lemmy.ml)
submitted 1 week ago by to c/linux@lemmy.ml
88 comments fedilink hide all child comments
 

Something good coming out of AI, it seems.

all 88 comments

sorted by: hot top controversial new old
[–] 15 points 1 week ago

Potential Linux security vulnerabilities.

  • permalink
  • fedilink
  • source
    •
    [–] 41 points 1 week ago* (last edited 1 week ago) (42 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.

  • permalink
  • fedilink
  • source
  • hideshow 42 child comments
    •
  • [–] 23 points 1 week ago (11 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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 11 child comments
    •
  • [–] 14 points 1 week ago (3 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 10 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.”

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 10 points 1 week ago* (last edited 1 week ago) (6 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 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

  • permalink
  • fedilink
  • source
  • parent
  • [–] 5 points 1 week ago (9 children)

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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [–] 8 points 1 week ago (7 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 0 points 1 week ago (4 children)

    By "bump" you mean the quadrupling of CVEs being addressed?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 1 week ago (2 children)

    Or being introduced. Or neither of those two, because it's an isolated graph devoid of larger context

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 week ago

    But we don't have enough information here; it says "CVE fixes per release", we don't know anything about them. Are these long-standing? Is some new process introducing security issues? We also have ongoing conversions of modules to rust, and lots of ongoing work.

    We can say AI tools are helping find these, and that may be true, but but this graph doesn't say that, it just says "CVE Number Big".

  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 1 week ago (16 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 16 child comments
    •
  • [–] 8 points 1 week ago (13 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 13 child comments
    •
  • [–] 2 points 1 week ago (1 child)

    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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 1 week ago* (10 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 0 points 1 week ago (6 children)

    There is no need to go older. We have 14 releases in between 6.9 and 7.2.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 1 week ago* (2 children)

    I think the other persons point is that if you were to start at 6.0 and sum all the CVEs until 7.0, the numbers would be similar to the CVEs from 7.0

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 week ago (1 child)

    This doesn't make sense. We are comparing single releases, not the entirety of 6.0 up to 7.0. How many years would this be? Also why do people want see 6.0? We have 14 last releases, in span of 2.5 years. And only the last two or 3 releases got a huuuge spike, which coincides with the broad usage and advancements of Ai in the Kernel.

    We don't need to compare older versions. The data is here and enough to support this claim. These are 14 releases for gods sake.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 week ago (2 children)

    I don't understand what you're saying... Those aren't major releases, those are dot releases, and they cross a major release.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 1 week ago (1 child)

    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).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 week ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 0 points 1 week ago

    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...

  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 1 week ago (1 child)

    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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 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.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 20 points 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.

  • permalink
  • fedilink
  • source
    •
    [–] 28 points 1 week ago (2 children)

    How many of them are new?

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
    • [–] 29 points 1 week ago (2 children)

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

  • permalink
  • fedilink
  • source
  • hideshow 2 child comments
    •
    • [–] 11 points 1 week ago (9 children)

    how many are introduced by new ai code?

  • permalink
  • fedilink
  • source
  • hideshow 9 child comments
    •
  • [–] 36 points 1 week ago* (6 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 14 points 1 week ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 7 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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 1 week ago (3 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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 3 points 1 week ago (2 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 7 points 1 week ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 1 week ago

    If this is primarily fixing old issues, over time we should see a sharp drop off and then even fewer security fixes then before due to fewer being introduced, due to being caught by AI upfront.

    On the other hand, if AI is introducing more issues than it is resolving, we’ll see the baseline of security issues being found permanently addressed.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 15 points 1 week ago (23 children)

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

  • permalink
  • fedilink
  • source
  • hideshow 23 child comments
    •
  • [–] 17 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).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 21 child comments
    •
  • [–] 1 point 1 week ago (16 children)

    Some people seem to be unable to fathom the fact that AI can be useful in some circumstances, always assuming the worst despite no evidence to suggest it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 16 child comments
    •
  • [–] 3 points 1 week ago (15 children)

    AI can be useful in some circumstances

    And the point is that this statement can be true AND we can still think AI should cease to be used. The "useful in some circumstances" benefit does not justify the ethical and environmental cost.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 15 child comments
    •
  • [–] 1 point 1 week ago (14 children)

    What would your preferred outcome in this situation be then? The bad guys are going to use AI to find exploits. What should the good guys do?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 14 child comments
    •
  • [–] 2 points 1 week ago

    Dollars to donuts says they don't have a preferred outcome, or at least not anything that amounts to more than wishful thinking.

    It's crazy how many people have only reactionary opinions that are largely divorced from reality when it comes to humanity's relationship with AI.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 1 week ago (12 children)

    What should the good guys do?

    Legislate AI away, except for the already existing open models that run on consumer-grade GPUs and are therefore orders of magnitude weaker and can't be used to break down any systems.

    Or penalize heavily any company developing a model that is subsequently used to invade a system, stopping this madness of separating the models from the operators of said models.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 12 child comments
    •
  • [–] 1 point 1 week ago (10 children)

    Legislate AI away

    Yes, because that has worked so well in the past for alcohol, cannabis, homosexuality, or nuclear proliferation.

    existing open models that run on consumer-grade GPUs and are therefore orders of magnitude weaker and can't be used to break down any systems.

    This class of models is already perfectly capable of finding and exploiting vulnerabilities in software, and is within spitting distance of the frontier.

    Or penalize heavily any company developing a model that is subsequently used to invade a system.

    Yeah, that case will be on the docket right behind U.S.A. vs Lockheed Martin, Northrop Grumman, and Raytheon surely.

    Do you seriously believe any of these are within the realm of possibility, or even believability?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 0 points 1 week ago (7 children)

    Yes, because that has worked so well in the past for alcohol, cannabis, homosexuality, or nuclear proliferation.

    A list of examples where prohibition didn't work is quite far from an argument that it never works, Plato. Leaded gasoline, CFCs, asbestos, DDT, should I go on?

    This class of models is already perfectly capable of finding and exploiting vulnerabilities in software, and is within spitting distance of the frontier.

    If you think frontier models are close to Qwen running on your 5090, you're completely devoid of any knowledge on the subject and therefore this discussion becomes meaningless.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 0 points 1 week ago (6 children)

    Your examples of prohibition and mine are not the same. Mine were purposefully chosen because they are or were contentious, just like AI is now.

    Your examples, on the other hand, outline situations where we were using something harmful that we did not realize at the time was harmful. Once that realization came to light, everyone agreed to stop. If you want to say this is the current situation with AI, then that's coherent. This is my olive branch to you.

    As for local models if you want to maintain that DSv4.1, GLM-5.3-f, M-3.1, or ther ilk are not near frontier-level. Then, I guess you are allowed to be wrong.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 0 points 1 week ago (5 children)

    As for local models if you want to maintain that DSv4.1, GLM-5.3-f, M-3.1, or ther ilk are not near frontier-level. Then, I guess you are allowed to be wrong.

    lol

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 0 points 1 week ago (2 children)

    Qwen 3.8 27b is now on par with claud fable 5 acording to this benchmark local llms are only a few months behind frontier models and are capable of many things.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 week ago (1 child)

    Fable is rank 5, Qwen 3.8 (with nothing claiming it's the reduced 27b one) is rank 29, fuck you are you talking about.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 week ago

    That's fable 5.1 I said fable 5. Also it seems like the link I sent wasn't for the benchmark I meant to send. Try to find the one for code rather than agentic work. Qwen 3.8 27B scores 1590 while Claude fable 5 scores 1624 which is a very slim margin considering fable 5 was one of, if not the best model when it was released.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 1 week ago

    I have softened very VERY slightly on AI code. If it can identify genuine issues than that is fine. It is when folks just trust it blindly and just send 50 commits without understanding a thing or even remotely testing it, that is just crazy. But then on the flip side, yeah all the other issues probably aren't worth it.

    It is complicated at times but then things like this always are. The most successful evil always has some claim to virtue.

    Alas, occasionally you have to walk with the devil to achieve some good. One just has to weigh up if it is worth it.

    I once asked Stallman about how he used to build and run GNU tools before having the Linux kernel. He was using a proprietary Minix system as a means to get work done until there was a better alternative. I mean running a proprietary system is one thing, burning through the amazon with 100 quintillion tokens is very different.

  • permalink
  • fedilink
  • source
  • parent
  • [–] -1 points 1 week ago (2 children)

    the very problematic ends AI is leading us towards anyway.

    Please Mr. Time Traveller. Tell us about the future.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 1 week ago (1 child)

    A plane's wings are burning and it's heading towards a mountain, opposite way to the nearest airport. Need a time machine to figure out what's about to happen?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 week ago

    I asked you to provide specifics about the future that AI is leading us towards, not a summary of the early 21st century. However, I understand how the question could have been confusing to one such as yourself who swims in the steam of prescience.

    Or, if we must stick to metaphor, where is AI in this airplane?

  • permalink
  • fedilink
  • source
  • parent
    • [–] 4 points 1 week ago

    The more fixed, the better.

  • permalink
  • fedilink
  • source
    •
    [–] 1 point 1 week ago* (last edited 1 week ago)

    Your dialectic skills truly know no bounds.

    Edit: I responded to the wrong person.

  • permalink
  • fedilink
  • source
    •
    [–] 1 point 1 week ago

    Just like most technologies, they aren't all bad or all good. In this case it's been good.

  • permalink
  • fedilink
  • source
    •