Forgot your password?
Close
typodupeerror
Bug Security Linux

Massive Debian 13 Linux Kernel Security Update Patches 68 Vulnerabilities (9to5linux.com) 47

Posted by EditorDavid from the going-through-a-rough-patch dept.
Slashdot reader prisoninmate shares this report from 9to5Linux: Coming ten days after the previous Linux kernel security update, which only fixed 12 vulnerabilities that may lead to a privilege escalation, denial of service, or information leaks, the new Debian 13 Linux kernel security update is a massive one, and it patches no less than 68 security vulnerabilities in the Linux 6.12 LTS kernel.

Debian 13 "Trixie" kernel security update are CVE-2026-64530, a use-after-free in the traffic-control subsystem leading to remote denial-of-service with potential for remote code execution, and CVE-2026-64531 (a.k.a. OVSwrap), a local-root vulnerability in the Open vSwitch datapath leading to local privilege escalation to root...

All Debian 13 "Trixie" users are urged to update their installations to Linux kernel 6.12.100-1 as soon as possible.

Massive Debian 13 Linux Kernel Security Update Patches 68 Vulnerabilities More | Reply

Massive Debian 13 Linux Kernel Security Update Patches 68 Vulnerabilities

Comments Filter:

  • 68 sounds really small by recent comparisons (Score:3)

    by evanh ( 627108 ) on Monday August 03, 2026 @03:59AM (#66269860)

    Isn't everyone patching 100s of vulns every month at the moment?

    • Re: (Score:2)

      by tlhIngan ( 30335 )

      Isn't everyone patching 100s of vulns every month at the moment?

      That would be fixed in the current tip of the kernel tree.

      But there are multiple supported kernel versions, and many vulnerabilities are not present in the older kernels so those will not be backported. Either the feature doesn't exist in the older kernel, or it isn't enabled by default, or there's a dependency on a newer kernel.

    • Not all of them are security updates. Not all of them are relevant to the kernel shipped by Debian.

    • This is only the kernel. Meanwhile, in the cases of windows and macos, the vuln count is against the whole OS.

      The correct comparison in that case would be against specific distros, not against the kernel.

  • Why so negative? (Score:5, Insightful)

    by HnT ( 306652 ) on Monday August 03, 2026 @05:08AM (#66269938)

    I am surprised at the many negative comments about the recently found CVEs, about Ubuntu patching LTS and the many other complaints and whining.

    Finding these bugs and patching them is a massive security win for Linux and F/OSS operating systems using Linux, and it is awesome to see how many people are working together to deliver these gains to everyone - FOR FREE!
    Backporting patches into LTS is pretty thankless but absolutely necessary.
    How about a bit more enthusiasm and thankfulness? You are getting an entire OS for free and get to keep (most of) your privacy. When was the last time you helped backport, or donated?

    • Exactly. On top of that, a typical apt update/upgrade takes less than a minute. For some users, the need for a reboot after a kernel update is a pain but you can do that when convenient.

      Any windows update beyond antivirus seem to take at least 30 minutes, uses half the machines resources, and requires a reboot (or two sometimes).

    • Backporting patches into LTS is pretty thankless but absolutely necessary.

      It's thankless, yes. Necessary, or even a good idea? I think that's debatable. Actually LTS is probably a good idea... but I'm very skeptical of SLTS. I don't think CIP is going to be successful at keeping 10 year-old kernel versions secure. If you need 10 years, you should either plan to do the work necessary to upgrade to new kernel versions periodically or you should assume that it's just going to be insecure and isolate it or otherwise shield it from attack.

      • I don't think CIP is going to be successful at keeping 10 year-old kernel versions secure. If you need 10 years, you should either plan to do the work necessary to upgrade to new kernel versions periodically

        The world is full of critical systems that are certified via an extensive (reads: expensive) process for a specific OS version which have an estimated useful life far longer than 10 years. One does not simply upgrade it, and typically the end user may not even be allowed to upgrade it.

        • I don't think CIP is going to be successful at keeping 10 year-old kernel versions secure. If you need 10 years, you should either plan to do the work necessary to upgrade to new kernel versions periodically

          The world is full of critical systems that are certified via an extensive (reads: expensive) process for a specific OS version which have an estimated useful life far longer than 10 years. One does not simply upgrade it, and typically the end user may not even be allowed to upgrade it.

          Everyone has to make their own decisions. I would discourage people from believing that SLTS kernels will be anything like secure by the end of their lifecycle. If that doesn't matter for some application, then fine. If it does matter then arguing that the SLTS kernel must be secure because recertifying is expensive is... not really an argument.

          FWIW, in my day job I'm making this same point to people building cars with an expected 20-year lifespan. I think the right conclusion is "Don't use Linux". If

      • My understanding of LTS is literally that I will absolutely get critical security patches for a long(er) time.
        I do not care about new features or fancy hardware support in LTS but gladly accept whatever trickles down, but the absolute main point for me is rock solid, reliable security patches in an acceptable timely manner. Everything else is secondary.

  • It turns out that, now that AI code review has gotten good enough, there is no difference, eyes wise, between open and closed source software.

    If anything, for most projects, paid commercial SW (FOSS or not) has an advantage, because they have the money to pay for the mechanical eyes without depending "on the kindness of strangers". The Linux kernel and some other big or well known non-paid-for projects will have no problem getting mechanical eyes. The smaller, or more obscure projects, not so much.

    ESR shoul

    • Re: (Score:1)

      by gweihir ( 88907 )

      Nonsense. And no, AI code review has very much NOT gotten "good enough". It just finds some stuff humans do not find, but it misses most stuff smart humans find.

    • What we're seeing is the superiority of open source over proprietary code. With open source, anyone can see the code, sick an AI on it and find many extreme edge case bugs, report them, and they get fixed. With proprietary code, only the corporation can see the code. Their AIs probably find even more bugs, because fewer eyes have ever looked for them in the past, but there is much less incentive for the corporations to fix them quickly. They control the publication and they control how much resource ( i.e.

  • LLMs are just finding a few bugs that humans did not because it has a different perspective on things. In a few months, we will be back to mostly or completely human-found bugs, most of which are completely out of reach of LLMs.

  • I've just compiled the latest 6.18 kernel, released this morning ("Mon Aug 3 11:22:13 2026 +0200" on the 6.18.42 commit message), and there's a 6.6, 6.12 and 7.1 as well. To my layman's eye there appear to be enough "leaks" and "corrupts" in the changelog to warrant security concerns. With the way Linux kernel CVEs work there won't be any yet, the team needs to now look at this new set of releases to judge each commit.

    So, expect another Debian kernel update in the next week or so.

  • I see [debian.org] some of these CVE's are fixed in trixie but not bookworm 6.1.177-1 (yet).

    Still other CVE's are fixed in bookworm but not yet in trixie. Seems like a few reboots are in the offing.

    First time I've seen several fixes in oldstable before stable. It must be a wild week over there. n.b. fixed, not 'not vulnerable'.

    Glad the oldstable crew is hard at work!

Slashdot Top Deals

"Unibus timeout fatal trap program lost sorry" - An error message printed by DEC's RSTS operating system for the PDP-11

Close