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.
Read more of this story at Slashdot.
Connexion
