{
  "id": 19902409,
  "title": "‘We need more reviewers’: Finding Linux bugs is easy now – fixing them is another story",
  "url": "https://urgent.news/2026/11/14/we-need-more-reviewers-finding-linux-bugs-is-easy-now-fixing-them-is",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-11-14T01:20:06.000Z",
  "source": {
    "name": "ZDNet",
    "slug": "zdnet",
    "url": "https://www.zdnet.com/innovation/ai-bug-reports-linux-windows/"
  },
  "original_language": "en",
  "account": "Microsoft’s FORGE Lab recently revealed that its AI scanning system, MDASH, discovered 59 upstream Linux kernel bug reports, including a flaw dating back 21 years. However, this number is not as alarming as it seems. Throughout 2026, the Linux Common Vulnerabilities and Exposures (CVEs) team reported an average of 27 CVEs per day. The reason behind this high number is simple: in Linux, any bug can potentially be a security bug. As Linux creator Linus Torvalds explained, \"Bugs will happen, and anything can be a security bug if somebody is clever enough to figure out how to abuse it.\"\n\nThe problem isn't just limited to Linux. Microsoft reported 726 CVEs in its latest Windows Patch Tuesday security release, with the majority coming from AI programmers. Finding bugs is no longer the difficult part; reviewing and fixing them is. Both Microsoft developers and kernel maintainers are struggling to keep up. Even an ARM engineer and Linux kernel maintainer, Lorenzo Stoakes, has given up reviewing code. Stoakes, who has been contributing to the kernel since 2014, said, \"Given the current throughput in the kernel resulting from AI-generated series, I unfortunately lack the bandwidth to generally be able to offer review except in those areas I maintain.\"\n\nThis situation is causing burnout among maintainers. Linux kernel stable maintainer Greg Kroah-Hartman shared his concerns during a Q&A session at Open Source Summit Europe, stating, \"We don’t have enough people to review them, the onslaught of the LLM-generated patches. We need more reviewers. We don’t have enough. All of the maintainers are burnt out, and we have been for ten years.\"\n\nDespite these challenges, there are some glimmers of hope. Linux Torvalds reported that much of the new code in the Linux 7.4 rc 2 was driven by AI fixes. He added, \"That on the bpf [Berkeley Packet Filter]- side at least the fixes are now coming in faster than the new reports, and that sounds lovely if true.\" However, he emphasized that most other areas haven't reached this point yet. Linux maintainer Greg Kroah-Hartman isn't as optimistic, saying, \"We are getting closer, yes, but not quite there yet.\" He isn't even willing to speculate on when human-approved AI fixes will catch up with and overcome AI bug reports.\n\nHowever, there is some cautious optimism. Open-source cURL project creator Daniel Steinberg believes they can manage the flood for now, though he remains critical of AI slop bug reports. Steinberg stated, \"We manage the flood pretty well so far, even if it goes a little up and down in periods depending exactly on who sends us a new set of findings this particular week.\"\n\nWhile AI bugs continue to be a significant headache, AI bug fixes, along with the work of thousands of maintainers, may eventually help stem the AI bug flood. However, this will require long hours and nights of work, and we can expect to see more serious security breaches in the future. November alone saw a serious Linux TCP networking security hole, an Alpine Linux OpenSSH flaw, a near-miss with Alpine's GitLab, and a wide-open PHP2Shell security issue, many of which still haven't been patched.",
  "summary": "Some Linux maintainers are quitting under the crushing strain of AI bug reports, while others see signs for hope.",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}