Linux 核心被 AI 找出的 bug 淹沒，審閱人力嚴重不足

在 Linux 核心裡找 bug，現在變得很容易；修復它們，卻沒那麼容易。根據 ZDNET 2026 年 11 月 12 日的報導，AI 工具如今產生的 bug 報告與修補程式太多，負責審閱的人已經疲於應付，至少一位知名的核心維護者已經不再審閱大部分程式碼。

CVE（Common Vulnerabilities and Exposures，通用漏洞揭露）是給已記錄的資安漏洞配發的公開編號。維護者（maintainer）是負責核心某一部分、並決定哪些修補程式可以合併的人，可能是志工，也可能是公司員工。審閱者（reviewer）負責閱讀他人提交的修補程式，並在合併前確認其正確。Linux 核心是從智慧型手機到超級電腦都在使用的作業系統核心，它仰賴的正是為數不多的這類人。

Linux 的 bug 報告洪流有多大？

根據 ZDNET 報導，截至 2026 年 11 月 2 日，Linux CVE 團隊 2026 年平均每天公布 27 個 CVE。ZDNET 認為這個數量部分源於核心特有的規則：在 Linux 中，任何 bug 都有可能是資安 bug。

根據 Tom's Hardware 轉述 Phoronix 8 月 28 日的報導，核心每個版本修復的 CVE 數量正接近 2000 個，而在 Linux 6.x 時代的大部分時間約為 500 個。穩定版核心維護者 Greg Kroah-Hartman 為 Kernel Recipes 2026 大會準備的一張投影片顯示，Linux 7.0 的數量超過 1000，Linux 7.2 超過 1500。如果趨勢延續，Linux 7.3 可能突破 2000，Tom's Hardware 指出。

Tom's Hardware 認為，這波暴增主要是因為有人用 AI 工具在一個 35 年間成長到超過 4000 萬行的原始碼樹裡大規模排查，而不是核心品質突然下降。這些工具能觸及人類很少再回頭檢視的冷僻角落，偶爾也能找到真正的缺陷：今年的 Linux CVE 紀錄中，已有由 AI 輔助靜態分析發現、後來經 Intel Product Security 確認的漏洞。

ZDNET 的文章還補充了企業端的數字。微軟 FORGE Lab 表示，其 AI 掃描系統 MDASH 向上游 Linux 核心提交了 59 份 bug 報告，其中一個缺陷至少存在了 21 年。根據該實驗室的說法，把這些發現整理成報告花了四個多人月，因為人力是瓶頸，並稱發現 bug 與修復 bug 之間嚴重失衡。在 Windows 方面，ZDNET 指出，最近一次 Patch Tuesday 包含 726 個 CVE，大部分來自 AI 驅動的漏洞發現。

核心維護者為什麼不堪重負？

壓力在一些有名有姓的個案中清楚可見。根據 ZDNET，2026 年 11 月 10 日，ARM 工程師、核心維護者 Lorenzo Stoakes 不再審閱記憶體管理核心、misc、reclaim 與 Rust 相關部分的程式碼，這些原本是他擔任審閱者所負責的區域。他自 2014 年起為核心貢獻程式碼。他寫道，面對目前 AI 產生的修補程式系列的吞吐量，除了自己維護的領域，他已沒有餘力提供一般性審閱。他還說，AI 產生的劣質內容起初偶爾出現，後來每週出現，再後來每隔幾天出現，如今約占他所見內容的一半甚至更多。

根據 ZDNET，穩定版核心維護者 Greg Kroah-Hartman 在 Open Source Summit Europe 的問答環節也說了同樣的話：沒有足夠的人來審閱 LLM 產生修補程式的洪流，維護者們已經倦怠了十年。他的訴求很直接：核心需要更多審閱者。

Tom's Hardware 提供了一個網路方面的量化例子。在 Linux 7.3 的網路合併請求中，維護者 Jakub Kicinski 估計，本週期處理的 648 個 net-next 修補程式中，有三分之一到一半看起來是由 AI 推動的低優先順序修復、清理或說明性修改。他寫道，團隊已經完全被淹沒。

工作量也在改變核心保留什麼。根據 Tom's Hardware，開發者 Andrew Lunn 在 4 月提議移除近 28000 行針對 ISA 與 PCMCIA 時代硬體的舊網路程式碼，因為 AI 與模糊測試工具開始發現缺陷，維護者覺得有義務修復，即使沒有人在使用這些硬體。Linux 7.3 正在移除舊的 SGI 與 IBM 驅動程式碼，FreeVxFS 檔案系統驅動程式也在其維護者表示這些陳舊的相容程式碼主要成了自動化 bug 檢查工具的目標後被移除。

核心社群是在拒絕 AI 嗎？

不是，Tom's Hardware 對此說得很明確。Greg Kroah-Hartman 本人就用在本機執行的 AI 輔助模糊測試工具找出過核心 bug。真正的不滿，針對的是未經驗證的 AI 輸出被丟給人類去核實。根據 Tom's Hardware，他最近禁止在核心 staging 子系統中提交 LLM 產生的修補程式，合法的資安修復除外；更新後的核心指南也警告，未經人工驗證就提交的 AI 產生報告可能浪費維護者的時間。團隊還取得了多個前沿模型的使用權，用來協助審閱修補程式並過濾掉幻覺產生的結果。

修復速度開始追上報告了嗎？

有早期跡象，但還不能下定論。根據 ZDNET，Linus Torvalds 在 Linux 核心郵件列表的一封郵件中寫道，Linux 7.4-rc2 中的大量新程式碼來自 AI 修復。他說，至少在 BPF 方面，修復現在比新報告來得更快，其他大多數領域還沒到這一步，這可能說明潮水開始轉向。他的建議是：先別抱太大期望。

Kroah-Hartman 沒有那麼樂觀。他對 ZDNET 說，專案正在接近，但還沒到那一步，並拒絕估計經人工核准的 AI 修復何時能超過 AI 的 bug 報告。cURL 專案的創建者 Daniel Stenberg 一向直言批評低品質的 AI 報告，他對 ZDNET 說，他認為到目前為止自己的專案應對這股洪流還算不錯，儘管數量會隨著某一週誰提交了新發現而起伏。

• 每天 27 個 CVE：根據 ZDNET，這是 Linux CVE 團隊截至 2026 年 11 月 2 日的平均值。
• 每個核心版本接近 2000 個 CVE，而 6.x 時代大部分時間約為 500 個，根據 Tom's Hardware。
• Linux 7.3 週期的 648 個網路修補程式中，有三分之一到一半被判斷為由 AI 推動的低優先順序工作，根據維護者 Jakub Kicinski。

這對企業意味著什麼？

對於在伺服器、容器、網路設備或嵌入式裝置上執行 Linux 的台灣企業來說，實際的啟示是：核心資安公告的數量會持續攀升，而每個修復背後的人手依然稀缺。單看 CVE 數量並不能說明風險，因為許多新項目涉及冷僻的驅動程式；關鍵是其中哪些影響您實際執行的硬體與核心設定。

由此可以養成三個習慣。追蹤所用發行版提供的穩定版核心更新，並縮短套用更新的時間。維護一份所啟用的核心功能與驅動程式的清單，以便快速分流公告。如果團隊借助 AI 提交 bug 報告，請先讓人重現每個問題，因為維護者自己的指南就說，未經驗證的報告會浪費他們的時間。仰賴 Linux 的企業也可以直接出力，出資或投入審閱時間，根據 Kroah-Hartman 的說法，這正是最稀缺的資源。

需要說明的是：這些來源沒有說明修復何時會超過報告，Torvalds 關於 BPF 的觀察也被描述為令人鼓舞但僅限於該領域。不妨把目前階段視為一個繁忙的修補季，而不是一個已經確定的趨勢。