Forgot your password?
Close
typodupeerror
AI Security Linux

Linux Kernel Team Publishes 432 CVEs In Two Days 35

Posted by BeauHD from the CVE-avalanche dept.
Ancient Slashdot reader alanw shares a post from the OSS Security mailing list, where sysadmin Jan Schaumann wonders what to do after the Linux kernel cranked out 432 CVEs in a little over 24 hours: "I understand the position that CVEs were always a flawed way to track or prioritize security changes... But this onslaught really shows it's not feasible to attempt to prioritize individual kernel changes. I'm not sure what to do here going forward." The Register reports: The nixCraft team speculated on social media that AI bug reports are a likely reason for all those kernel CVEs, which wouldn't be without precedent - Linus Torvalds himself said in May that the Linux kernel security mailing list had become "almost entirely unmanageable" due to AI-assisted bug hunting. Nonetheless, Torvalds has described AI as a useful tool for Linux development while still noting it can be a drag for maintainers, both from a workload standpoint and the fact "it keeps finding embarrassing bugs." [...]

Unfortunately for Linux sysadmins, the position in which they find themselves in this current mess isn't one that's readily solved. CVEs might be a messy way to track and prioritize security updates, especially when hundreds of them are published over a short period, but without something better, it falls to IT and security teams to determine which vulnerabilities affect their systems and which kernel updates they need to deploy. Senior kernel maintainer Greg Kroah-Hartman replied to Jan's post, pushing back on the idea that the kernel's CVE volume is uniquely unmanageable. The kernel isn't special, he argues -- companies everywhere are finally realizing they need to re-evaluate how they update all of their systems and devices, something that's traditionally been "woefully ignored."

On the "just always update" approach, Greg says that's precisely what the kernel community endorses: "This is what the kernel developer community recommends and supports. If you want support from us, do this." Can't manage it yourself? Pay a company for support, or "just use Debian or Yocto as their security practices are amazing." He points to Android as proof the approach scales, calling it "the largest deployment of software in the world" -- billions of devices kept updated "with one very-overworked developer guiding it all."

As for reviewing every CVE individually, he notes this can be largely automated by intersecting the files a CVE touches with the files you actually build, which typically trims the relevant set "down to about 10% of the overall total" -- the approach enterprise distros already take for their customers. Panic-mode selective patching gets a blunt "Good luck with that!" -- regulations like the EU's Cyber Resilience Act are set to legislate that habit away ("rightfully so," in his view), and "your insurance company might wish to have a talk with you as well."

Greg also warns the flood isn't over: "The number of llm-found issues is only on the rise right now, it's going to be a very long 18 months at the least to dig ourselves out of this mess, and people had BETTER be updating their systems all along the way if they expect to be secure in any way." As for the 432-CVE burst itself, he explains it was simply him catching up on a weeks-old, publicly visible review queue over the weekend -- delayed by "a perfect storm of 6 weeks straight of conferences and vacations" -- so it shouldn't have come as a surprise to anyone watching the public git repo.

Linux Kernel Team Publishes 432 CVEs In Two Days More | Reply

Linux Kernel Team Publishes 432 CVEs In Two Days

Comments Filter:

  • It's always better for the team and users to be aware of vulnerabilities than to be unaware.

    • Re: (Score:2)

      by CEC-P ( 10248912 )
      People out there complaining that it's too much work or makes them look bad. Ummm, would you rather have someone else find them instead of the devs? How is that better? Get over it and fix it.

      • Re: (Score:2)

        by jhoegl ( 638955 )
        They already did find them... thats why they are CVEs. So at a minimum a few people know about them if not tons more.
        Security through obscurity never works. Eventually, it gets found out.
    • The issue isn't awareness, it is how to process such massive amounts of data. This is more than the average security/IT team can possibly process in a timely manner. yes it is a good thing or at least a necessary thing, it is still a very fucked up thing.

      • Re: (Score:2)

        by SeaFox ( 739806 )

        The issue isn't awareness, it is how to process such massive amounts of data. This is more than the average security/IT team can possibly process in a timely manner.

        Sounds like they need to increase their staffing then. I wonder if there are any IT people looking for jobs right now...

      • Re: (Score:2)

        by Tailhook ( 98486 )

        This is more than the average security/IT team can...

        Don't care. You've had time: this is no surprise to anyone that's been paying the least bit of attention for several years now, and isn't still stupidly indulging AI denial. The excuse window has closed: if your business is security and you didn't know at least as 18 months ago that you could expect to see exactly what is happening today, you're a seat warmer and no one cares what you think. And you're going to be obsolete soon as well.

        • Re: (Score:2)

          by Junta ( 36770 )

          Note that this isn't even new to AI, the kernel has always been a flood of CVEs. The AI spotlight puts a bigger spotlight on it, but it has been a mess.

          The real problem is that the average security team is mismanaged and forced to use terrible tools that report on yet fail to reconcile the status of the CVEs on behalf of the user and instead drives the team to have to figure out how to take care of it themselves.

          Some twisted security mindset of going direct with CVEs as 'the most thorough vendor neutral ap

    • Re: (Score:2)

      by Junta ( 36770 )

      Depends on the number of realistically 'false positives'.

      I've known a few people who find the kernel CVEs particularly unreasonable as they tend to aggressively assume security implications. If they grant a CVE to a 'mere bug', no one is going to get too grumpy over that specific item. If someone believes they have a vulnerability and do not see a CVE, then people get riled up. So some feel the kernel is just granting CVEs to avoid pushing back.

      The other headache is the monolithic nature of the project.

  • Is there any other kind?

    • Is there any other kind?

      Sure there are. Some bug reports, you look at them and dig in and say "Damn, that's obscure. It depends on subtly-wrong but arguably-correct-in-isolation mistakes in four different places. How the hell did they even find that?".

      Granted that it's more common to glance at it and just be ashamed, or to look at it and say "Really? You think an attacker can do A, B, C, D, and E, all at the same time? Oh, and to do B or D they'd already have to have the system mostly compromised. Okay, I'll fix it, but no

  • They have an unparalleled level of oversight and accountability for a free distribution. It's worth dealing with the outdated packages. These days, on topic, at least you can get current kernels from backports.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Running Debian with your own kernels is easy, except for the really deranged grub automation. I mount /boot ro to prevent it getting clobbered all the time.

      • I did it for a while, it's nice that they package the necessary files with the kernel, but it's nicer to not have to. These days I get a current kernel and a ntsync module without having to do anything special.

  • In the industry, so many security teams mandating CVE management software that is absolutely stupid and pushes off all the hard bits to the user.

    It sees 6.12.0-211.34.1.el10_2... Well... none of that makes sense so it just assumes that it's just plain 6.12.0 and demands the user reconcile the reality. Now the security vendor *could* maybe integrate with the major linux distributions advisories... But no, more CVEs is better, when you demo that your product finds hundreds of CVEs, that just proves it is be

  • Even before tools like Mythos were made available, security professionals were seeing a large increase in AI detected bugs, some of which were, indeed, critical (Mythos and it's ilk have only increased the numbers). The statements of those security professionals were that the next few years are going to be some of the most intense that the security teams have ever experienced, but that it was likely things will eventually get better for those that are able to survive the storm (and not everyone will) as t

    • Re: (Score:3)

      by Junta ( 36770 )

      Most maddening for open source projects is the number of false positives exacerbated by multiple people trying to 'help' by running effectively the same security audit as a bunch of other people have done and trying to open issues that are duplicate...

      Huge pain in the ass dealing with contributions from people who don't understand enough to analyze their LLMs "findings" and just pass them through "in case they are helpful".

      Might be nice once the fad of "everyone contribute by running duplicate reviews" subs

    • Re: (Score:2)

      by gweihir ( 88907 )

      It is actually not that many, because the LLM peddlers are massively overstating things. And it is not even hard to find ones. For example, those "273 zero-days in FF" turned out to be 3 (!) in the actual patch notes, two of them use-after-free which really do not need LLMs to be found. GCC can do it. Good coding practices (setting pointers to NULL after freeing memory) prevent exploitability.

      My take is these CVEs will be a lot of low-risk ones, many without exploits. In a kernel, these should definitely be

      • My take is these CVEs will be a lot of low-risk ones, many without exploits

        Should be extremely simple, right? Just ask the LLM to write an exploit. Should be easy in an agentic chain. Too bad LLMs can't actually compile code.

        • Re: (Score:2)

          by gweihir ( 88907 )

          No, I meant there may not be known exploits. Using an LLM does not change that. The thing is, many potential security bugs are really "risks" and it is not clear whether they are exploitable. May require special circumstances that are unknown. May actually be prevented by something else, but that something else can break in the future. May require a race-condition with really low probability and that is only there on some hardware. May not be exploitable at all, but better be careful. In a kernel, defensive

          • No, I meant there may not be known exploits. Using an LLM does not change that.

            OK, ask the LLM to create some known exploits. If you're agentic, you can have it submit the patch automatically. Then if the kernel team is sufficiently agentic, they can approve the patch automatically and get it integrated. They are not quite there yet, but we don't need to do anything.

            These problems all have solutions.

            • OK, ask the LLM to create some known exploits. If you're agentic, you can have it submit the patch automatically. Then if the kernel team is sufficiently agentic, they can approve the patch automatically and get it integrated.

              I hope we NEVER get there. The last thing you want to do is let automated systems automate their own solutions that are automatically pushed out without any human overview and testing. You will suddenly wake up one day to "your" system farming crypto tokens for some random wallet somewhere....

  • I.e. low-hanging fruit being found because AI looks at things a bit differently. Should clear up soon.

    Kind of does not make the kernel much more secure in general as AI only finds simple to find bugs, but needs to be done as attackers will use AI as well. Unfortunately, attackers can randomize the process, so this helps only against low/no-clue LLM-based attacks. But the no-clue AI fueled attackers are going to be a real problem for a while, hence this still is a good thing. Just do not read too much into i

  • Does the kernel create a foundation to pay people for support? Do distros pay a kernel foundation for support? Do you charge everyone for kernel use? So of course android is a convenient example of success because the only way any of these options can resolve is an eventual closed source pivot and absorption in to a larger bloated closed source environment.
  • While the Linux kernel is open source, making it easier for AI systems to detect bugs, proprietary closed-source software has even more reason to worry.
    AI is advancing rapidly and will become increasingly capable of analyzing machine code directly to uncover vulnerabilities and defects.
    And unlike open-source projects, there won't be a large community ready to help identify, fix, and review those issues.

    The clock is ticking...

Slashdot Top Deals

Five is a sufficiently close approximation to infinity. -- Robert Firth "One, two, five." -- Monty Python and the Holy Grail

Close