Linux kernel team publishes 432 CVEs in two days

Summary

security Linux kernel team publishes 432 CVEs in two days Sunday-to-Monday onslaught fuels speculation over AI-assisted bug reports If you're responsible for Linux security, someone just dumped a pile of work onto your desk: 432 Linux kernel CVEs were published across Sunday and Monday this week. Linux watchers at nixCraft pointed out the volume on Monday morning, and it didn’t take long for seasoned sysadmins to start expressing concerns.Jan Schaumann, chief information security architect at Akamai Technologies, took to the OSS-SEC mailing list Tuesday to express concerns over the sheer volume of Linux kernel CVEs published in recent days. Aside from noting that the CVE system isn’t the best way to track security changes, Schaumann also wondered in his post whether there was any good way to deal with so many kernel security issues.“This onslaught really shows it's not feasible to attempt to prioritize individual kernel changes,” Schaumann said. “You might attempt to process this large set of changes by pointing an LLM at the intake and asking it to prioritize them,” he suggested, “but if it spits out a dozen today and another 25 the next, you haven't won much.” Schaumann also suggested waiting to see which ones emerge as serious issues and focusing on those in the weeks to come, or updating one’s entire fleet of Linux machines on a weekly basis. “I sure would like to be able to do [that], but reality keeps getting in my way,” Schaumann said. “I'm not sure what to do here going forward.”In an email to The Register, Schaumann said that individually reviewing vulnerabilities for patching was already difficult enough before things rose to this level, and that automation may be the only option - but it's not a great one. "Automated, regular, and frequent updates that pull in all changes within a given time window of tolerance seem to me the only reasonable approach, but that is very difficult for many large organizations," Schaumann explained. Those orgs often rely on l...