The arrival of large language models as an everyday bug-hunting tool has turned the security-report intake of free-software projects into a sustained flood, and the Linux kernel — among the most visible targets in the open-source world — is now openly grappling with the consequences.
Greg Kroah-Hartman, one of the kernel's most prominent maintainers, took the stage at the 2026 edition of Kernel Recipes to explain how the kernel security team is handling the deluge, according to coverage published by LWN.net. To a community whose report volume has transformed in a very short time, his central message was blunt: "don't panic."
LWN's coverage appears behind a paywall and offers a limited window into what Kroah-Hartman said in detail, but the framing of the problem is difficult to miss. LLMs have substantially lowered the cost of finding security vulnerabilities in widely deployed code. What was once the work of skilled security researchers or paid bug-bounty hunters can now be attempted at scale by anyone with a chatbot and a target project — producing reports in volume that maintainers' triage processes were never designed to absorb.
Kroah-Hartman's point, as presented in LWN's account, is that the kernel community's existing mechanisms for dealing with incoming reports remain fundamentally sound, and that the appropriate response to rising volume is disciplined triage rather than alarm. That is a significant message, because the bottleneck in kernel security under report pressure is rarely the fix itself — maintainers routinely close genuine vulnerabilities quickly once a report is properly qualified. The scarce resource is the phase that comes before: the senior technical judgment needed to decide whether a given report describes a real, exploitable, relevant bug — an assessment no model can perform on its own and one that consumes attention repeatedly as similar issues arrive under different wording.
For organizations running large Linux estates — from banks and insurers to telecom operators and public-sector platforms — the operational implication is straightforward. A tool that produces a vulnerability report has not, by itself, produced a security incident. Treating automated scanner or LLM-generated output as a hypothesis to be qualified, rather than as an actionable ticket, mirrors exactly the discipline Kroah-Hartman is asking of kernel maintainers.
This gap is also the one most likely to strain enterprise patch-SLA commitments. Fix-to-deployment timelines are typically well instrumented and well resourced; report-arrival-to-triage-qualification often depends on security engineers who are simultaneously handling other fires. Under sustained volume pressure, that is the interval most likely to slip quietly — and the one least visible to anyone signing off on SLA compliance.
Worth noting is that the kernel is, in many respects, the best-resourced open-source project on earth, with a large, experienced maintainer base and established reporting infrastructure. If that project is publicly asking its maintainers to manage their response to an automated-reporting surge, smaller projects — web frameworks, language runtimes, container tooling, embedded libraries — with a fraction of that capacity are likely to feel the pressure earlier and harder. Downstream distribution and security-operations teams have a direct interest in how those upstream communities respond, and in which of their dependencies are most exposed.
Kroah-Hartman's "don't panic" framing will not silence the debate over AI-generated vulnerability reports, but the message the kernel community is choosing to make loudly — that automated discovery is a solvable process problem, not an existential one — is one worth internalizing before the next surge arrives. What acceptance criteria maintainers should set for plausible but unverifiable reports, and how such reports should be attributed when they cannot be traced to a human researcher, remains genuinely open.
Editorial note: This piece is based on LWN.net's report of Greg Kroah-Hartman's talk at Kernel Recipes 2026. LWN's coverage is behind a paywall, and slides or recordings from the event were not available at the time of writing; direct quotation and process detail beyond the "don't panic" message could not be independently verified. No figures have been cited because none were confirmable from accessible sources. Should primary materials become available, this report may be updated with additional specifics.
大型語言模型（LLM）成為日常尋找漏洞的工具後，自由軟件項目的安全報告接收流程持續承受大量報告衝擊，而作為開源世界中備受矚目的目標之一，Linux 核心目前正面對此帶來的後果。
Linux 核心其中一位最知名的維護者 Greg Kroah-Hartman 在 2026 年的 Kernel Recipes 大會上發言，解釋 kernel 安全團隊如何應對這股報告洪流，根據 LWN.net 的報道。面對一個報告數量在極短時間內急增的社群，他傳達的核心信息十分直接：「不要恐慌。」
LWN 的報道設有付費牆，僅提供 Kroah-Hartman 言論的有限視角，但問題的定性依然清晰可見。LLM 已大幅降低在廣泛部署的代碼中尋找安全漏洞的成本。以往需要資深安全研究員或有償 bug-bounty 獵人處理的工作，如今任何擁有聊天機械人及目標項目的人均可大規模嘗試，產生的報告數量遠超維護者的分類處理流程（triage process）所能消化的水平。
根據 LWN 的記述，Kroah-Hartman 的觀點是：kernel 社群處理各類報告的現有機制在根本上仍然健全，面對報告量增加，適當的回應是嚴謹的分類處理（triage），而非恐慌。這個信息意義重大，因為在報告壓力下，kernel 安全工作的瓶頸很少在於修復本身——只要報告經過妥善查核，維護者往往會迅速關閉真正的漏洞。真正稀缺的是之前那個階段的工作：需要資深技術判斷力來決定某份報告是否描述了真實、可利用且相關的漏洞——這種評估任何模型均無法獨立完成，並在類似問題以不同措辭再次出現時反覆耗費注意力。
對於營運大規模 Linux 系統的機構——從銀行、保險公司到電訊營運商及公共部門平台——其運作上的影響十分直接：產生漏洞報告的工具本身，並未構成一宗安全事件。將自動掃描器或 LLM 生成的輸出視為有待查核確認的假設，而非可立即執行的工單（ticket），正好與 Kroah-Hartman 對 kernel 維護者的要求一致。
這個缺口也最有可能令企業的 patch SLA 承諾面臨壓力。從修復到部署的時限通常有充分的監測與資源投入；但從報告到達、到通過分類查核的環節，往往取決於同時應對其他緊急事項的安全工程師。在持續的報告量壓力下，這正是最可能無聲延誤的時段，也是負責簽署 SLA 合規的人最難察覺的環節。
值得注意的是，kernel 在多方面均是全球資源最豐厚的開源項目，擁有人數眾多、經驗豐富的維護者團隊及成熟的報告基礎設施。如果這個項目都要公開要求其維護者管理自動化報告激增的應對方式，那些規模小得多的項目——網絡框架、語言 runtime、container 工具、嵌入式函式庫——只有 kernel 資源的一小部分，很可能會更早、更沉重地感受到壓力。下游發行版及安全營運團隊對這些上游社群的應對方式，以及其依賴項目中哪些風險最為暴露，有直接的切身利益。
Kroah-Hartman「不要恐慌」的定調，不會平息圍繞 AI 生成漏洞報告的爭論，但 kernel 社群選擇高調傳達的信息——自動化發現是可解決的流程問題，而非存在性威脅——值得在下一波報告洪流來臨之前深入領會。維護者應如何為「看似合理但無法驗證」的報告設定接受標準，以及當這類報告無法追溯至人類研究員時應如何署名，仍然懸而未決。
編按：本文基於 LWN.net 對 Greg Kroah-Hartman 在 Kernel Recipes 2026 演講的報道。LWN 的報道設有付費牆，截至撰稿時並無大會的投影片或錄像可供查閱；除「不要恐慌」的信息外，直接引述及流程細節均無法獨立核實。文中未有引用任何數字，因為均無法從可接觸的來源確認。若原始材料公開，本文或會補充更多具體內容。