security<\/p>\n
Sunday-to-Monday onslaught fuels speculation over AI-assisted bug reports<\/p>\n
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<\/a> out the volume on Monday morning, and it didn\u2019t take long for seasoned sysadmins to start expressing concerns.<\/p>\n Jan Schaumann, chief information security architect at Akamai Technologies, took to the OSS-SEC mailing list Tuesday to express concerns<\/a> over the sheer volume of Linux kernel CVEs published in recent days. Aside from noting that the CVE system isn\u2019t 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.<\/p>\n \u201cThis onslaught really shows it’s not feasible to attempt to prioritize individual kernel changes,\u201d Schaumann said.\u00a0<\/p>\n \u201cYou might attempt to process this large set of changes by pointing an LLM at the intake and asking it to prioritize them,\u201d he suggested, \u201cbut if it spits out a dozen today and another 25 the next, you haven’t won much.\u201d<\/p>\n Schaumann also suggested waiting to see which ones emerge as serious issues and focusing on those in the weeks to come, or updating one\u2019s entire fleet of Linux machines on a weekly basis.\u00a0<\/p>\n \u201cI sure would like to be able to do [that], but reality keeps getting in my way,\u201d Schaumann said. \u201cI’m not sure what to do here going forward.\u201d<\/p>\n 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.\u00a0<\/p>\n “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 lengthy QA processes, slow and staged development cycles, and may even have contractual requirements for long-term support that make an automated approach an impossible one.\u00a0<\/p>\n The nixCraft team speculated on social media that AI bug reports are a likely reason for all those kernel CVEs, which wouldn\u2019t be without precedent – Linus Torvalds himself said in May that the Linux kernel security mailing list had become \u201calmost entirely unmanageable<\/a>\u201d due to AI-assisted bug hunting. Nonetheless, Torvalds has described AI<\/a> 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.”<\/p>\n On that note, it’s worth understanding what a Linux kernel CVE actually means – many of the vulnerabilities included in the Sunday-to-Monday batch are small in scope, but they’re vulnerabilities nonetheless.<\/p>\n As senior Linux maintainer Greg Kroah-Hartman noted in a February blog post<\/a>, the Linux kernel CVE team follows the CVE Program’s definition of a vulnerability: a weakness in a product that can negatively affect a system’s confidentiality, integrity, or availability.<\/p>\n \u201cAt the level that the Linux kernel runs, almost any type of bug that can affect a running system can be classified as a vulnerability,\u201d Kroah-Hartman noted. The kernel team looks at every bugfix that is added to stable kernel releases, he added, and if it fixes an issue that meets that CVE criteria, a CVE is assigned.\u00a0<\/p>\n AI-assisted bug hunting has increased the volume of reports reaching Linux kernel maintainers. We reached out to the Linux kernel team, but didn\u2019t hear back. Kroah-Hartman did tell The Register\u00a0earlier this year that AI bug reports had become worthwhile<\/a> in recent months, and he predicted they’re likely to keep adding to his workload.\u00a0<\/p>\n Unfortunately for Linux sysadmins, the position in which they find themselves in this current mess isn\u2019t one that\u2019s 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.<\/p>\n