負責 Linux 核心穩定版的 Greg Kroah-Hartman 提出警告，開發中的 Linux 7.3 恐怕又是一個難熬的週期。原因既非安全漏洞，也不是設計缺陷，而是 AI 工具找出並送交的大量錯誤修補程式。8 月 30 日公開的 7.3-rc1 是核心史上規模數一數二的版本，而每個版本登錄的漏洞件數正逼近 2,000 件。
單一收件匣裡堆積的 4,000 多封未處理修補
Kroah-Hartman 在開發者取向的社群平台 social.kernel.org 上公開了自己負責的 USB 子系統信箱狀況。短短數週累積的未處理郵件遠超過 4,000 封，容量達數十 MB。即使先行處理掉明顯屬於錯誤修正的部分，以及已被新版本取代的舊投稿，剩下的仍有 4,000 封以上。用他自己的說法，這仍然很誇張。
麻煩的地方在於，這座小山無法用機械的方式丟棄。他確實經常對 AI 生成的投稿提出退回，但也表示不願意直接拒絕那些明顯是錯誤修正的內容。不讀內容就無法判斷，而閱讀本身就要耗費人力。瓶頸正卡在這裡。
在他同時照看的 staging 分支中，他已訂下除了真正的安全修正之外，不接受 AI 或 LLM 生成修補程式的方針。這並非全面禁止，而是先把雜訊最多的區塊關上。
7.3-rc1 成為史上第二大的合併視窗
7.3 的合併視窗在兩週內納入 15,267 次提交，以核心史上第二大的規模收尾。連同註解與空行計算，程式碼行數達到約 40,980,000 行，相較於 7.2 的 40,420,000 行大幅增加。其中被判定為實際程式碼的約 30,940,000 行，註解約 4,910,000 行，空行約 5,130,000 行。
不過，這次膨脹的主因並不是 AI。rc1 修補中將近三分之一，來自 AMD 為下一代 GPU 投入的 DCN6 顯示暫存器標頭檔與相關程式碼。結果光是 AMD 的圖形驅動程式目錄就達到約 6,520,000 行，約占整個核心的 16 個百分點。當接近機器產生的龐大標頭檔一次併入時，統計上的行數自然會暴增。
此外，7.3-rc1 也帶來對 AMD Zen 6 世代的支援、Btrfs 的效能改善，以及 2026 年版 Steam Controller 的支援。穩定版的釋出時間以 10 月 18 日為目標，若收尾階段過於吃緊，有可能順延一週至 10 月 25 日。
每個版本逼近 2,000 件的漏洞登錄
比修補數量更具象徵意義的，是登錄為 CVE 的漏洞件數。根據 Kroah-Hartman 為預告 Kernel Recipes 2026 演講所展示的簡報，6 系時代每個版本約 500 件，到 7.0 突破 1,000 件，7.2 再越過 1,500 件。若這個斜率持續下去，7.3 將達到 2,000 件。
這並不代表 Linux 突然變得脆弱。真正的情況是，手握 AI 工具的探查者開始地毯式檢視這個歷經 35 年、超過 40,000,000 行的龐大程式碼庫。實際上，登錄的案件大多優先度偏低，或者牽涉到已不再使用的驅動程式與廢止的功能。
叫苦的並不只有 USB 的負責人。負責網路領域維護的 Jakub Kicinski 在給 7.3 的拉取請求中報告，本週期處理的 648 個 net-next 修補中，有三分之一到一半看起來是 AI 引起的低優先度修正、整理或敘述釐清，並寫下團隊已經完全忙不過來。
來源是靜態分析工具
Kroah-Hartman 指出，目前送達的修補程式絕大多數出自靜態分析工具。被點名的內容多半是「用奇怪的方式使用才可能踩到」這一類相當古老的輕微問題。理論上並沒有錯，但是否真有使用者因此困擾就很可疑。即使如此，它們仍然成立為有效的回報，於是維護者的判斷成本不斷累積。
另一方面，也有作為副產品被整理掉的部分。以 AI 引起的錯誤回報增加為契機，今年以來舊驅動程式群獲得整頓，ISDN 子系統整個被移除。那裡先前潛藏著數十件 CVE，因此就清理而言成果相當可觀。從推動盤點被擱置的程式碼這一點來看，眼下的局面也有一定的效用。
問題在於，與這份效用相稱的人力並未到位。Kroah-Hartman 這數個月來在演講場合反覆提到「這會是漫長的 18 個月」，而他表示這個數字絲毫沒有縮短的跡象。
總結
Linux 7.3 將帶著大量 AI 生成的錯誤修補與漏洞回報走向 10 月的釋出。7.3-rc1 以 15,267 次提交、超過 40,980,000 行的規模成為史上第二大的合併視窗，CVE 登錄則有逼近每個版本 2,000 件之勢。被點出的問題大多古老且輕微，但既然無法機械地拒絕明顯的修正，查核的負擔就集中在人類維護者身上。舊程式碼盤點帶來的好處，與維護者消耗所付出的代價，究竟哪一邊比較大。接下來受到考驗的，將是開發體制這一側該如何補強。
