Linux Kernel Team Publishes 432 CVEs In Two Days
(Wednesday July 22, 2026 @05:00PM (BeauHD)
from the CVE-avalanche dept.)
- Reference: 0184588594
- News link: https://linux.slashdot.org/story/26/07/22/2033256/linux-kernel-team-publishes-432-cves-in-two-days
- Source link:
Ancient Slashdot reader [1]alanw shares [2]a post from the [3]OSS Security mailing list , where sysadmin Jan Schaumann wonders what to do after the Linux kernel [4]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 [5]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 " [6]almost entirely unmanageable " due to AI-assisted bug hunting. Nonetheless, Torvalds has [7]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 [8]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 [9]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.
[1] https://slashdot.org/~alanw
[2] https://slashdot.org/submission/17349174/oss-security-432-linux-kernel-cves
[3] https://seclists.org/oss-sec/2026/q3/198
[4] https://www.theregister.com/security/2026/07/22/linux-kernel-team-publishes-432-cves-in-two-days/5276497
[5] https://mastodon.social/@nixCraft/116953574480188144
[6] https://linux.slashdot.org/story/26/05/18/0238214/linus-torvalds-ai-detected-bug-reports-make-kernel-security-list-almost-entirely-unmanageable
[7] https://linux.slashdot.org/story/26/07/17/1830258/linus-torvalds-to-critics-of-ai-coding-on-linux-fork-it-or-just-walk-away
[8] https://seclists.org/oss-sec/2026/q3/210
[9] https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
> The nixCraft team [5]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 " [6]almost entirely unmanageable " due to AI-assisted bug hunting. Nonetheless, Torvalds has [7]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 [8]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 [9]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.
[1] https://slashdot.org/~alanw
[2] https://slashdot.org/submission/17349174/oss-security-432-linux-kernel-cves
[3] https://seclists.org/oss-sec/2026/q3/198
[4] https://www.theregister.com/security/2026/07/22/linux-kernel-team-publishes-432-cves-in-two-days/5276497
[5] https://mastodon.social/@nixCraft/116953574480188144
[6] https://linux.slashdot.org/story/26/05/18/0238214/linus-torvalds-ai-detected-bug-reports-make-kernel-security-list-almost-entirely-unmanageable
[7] https://linux.slashdot.org/story/26/07/17/1830258/linus-torvalds-to-critics-of-ai-coding-on-linux-fork-it-or-just-walk-away
[8] https://seclists.org/oss-sec/2026/q3/210
[9] https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
it keeps finding embarrassing bugs. (Score:2)
by kid_wonder ( 21480 )
Is there any other kind?
Re: bubbles (Score:2)
by drinkypoo ( 153816 )
We know you're a POS due to your language choices
nobody can predict the winners (Score:2)
by OrangeTide ( 124937 )
You should simultaneously believe both that nearly all AI investment is a bubble and also that AI tools are not going way.
Debian is indeed good (Score:2)
by drinkypoo ( 153816 )
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.
Great news (Score:2)
It's always better for the team and users to be aware of vulnerabilities than to be unaware.
Re: (Score:2)
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)
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.
Re: (Score:2)
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)
> 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)
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.