一個無人預期的副作用
AI 輔助安全掃描的出發點是好的：讓工具找到人眼容易錯過的漏洞，提升軟體品質。但在 Linux 核心社群，這個工具正在產生一個沒有人預期的後果——它找漏洞的速度，已經超過了人類維護者能夠處理的極限，而最終受害的，是一批在核心裡沉睡了 30 年的舊驅動程式。
Andrew Lunn 的提案
2026 年 4 月，知名 Linux 核心維護者 Andrew Lunn 提出一份移除提案，目標是砍掉以下這些長期無人使用的子系統：
- ISDN 子系統（整合服務數位網路，1990 年代的撥接技術）
- ISA 與 PCMCIA 時代的乙太網路驅動（3Com、AMD、SMSC、Cirrus Logic、Fujitsu、Xircom 等品牌）
- 業餘無線電協議（AX.25、NET/ROM、ROSE）
- ATM 協議與驅動
總計約 27,646 行程式碼，若加上 Linus Torvalds 後來合併的完整批次，則達到 138,000 行。
Lunn 的理由直白：「這些舊驅動過去維護起來不費什麼力氣，直到最近。現在有越來越多的新手使用 AI 和模糊測試工具來找問題，結果反而讓維護者增加了更多工作。」
AI 製造的維護地獄
問題的核心是一個不對稱性：AI 工具可以在幾秒內對數萬行程式碼進行靜態分析，找到理論上的安全問題，但人類維護者驗證每一份回報都需要時間與判斷力。
這些舊驅動的程式碼本身不算複雜，但它們的硬體幾乎已從市場消失。當 AI 掃描工具在 AX.25 業餘無線電協議或 ISDN 堆疊裡回報漏洞時，維護者面臨的處境是：
- 沒有辦法在真實硬體上重現問題
- 不確定這個漏洞在現實中是否有任何可被利用的攻擊面
- 但又不能直接無視，萬一是真的呢？
這種兩難讓每一份 AI 生成的 bug report 都變成一份強迫驗收的作業，積累下來，就成了 Lunn 所說的「不成比例的維護負擔」。
LWN.net 的社群討論：不只是技術問題
這份提案在 LWN.net 引發了有深度的社群辯論。反對聲音主要來自兩個角度：
工業用途的現實：有評論者指出，工業與嵌入式設備的生命週期往往長達數十年，某些仍在運行的設備確實依賴這些協議。「你的伺服器農場每隔幾年就換代，但電廠的 SCADA 系統可能跑了 20 年還沒換。」
無人維護的假象：另一評論點出更深層的問題——這些程式碼之所以看起來「被維護」，只是因為它藏在 Linux 這個大型專案裡；如果它是獨立的開源專案，早就因為無人更新而被宣告死亡。「它一直在假裝被維護。」
Lunn 的回應是提供緩衝機制：如果有企業或個人願意接手成為真正的維護者，驅動可以留下。否則，就移除。
這個事件的結構性意義
過去，核心程式碼被移除的理由通常是「沒人用了」或「有更好的替代方案」。這次不一樣——觸發因素是 AI 工具產生的外部壓力。
這建立了一個新的邏輯：程式碼不只可以因為無用而死，也可以因為「吸引了太多 AI 製造的雜訊」而死。對於任何長期維護大型開源專案的人來說，這是一個值得認真看待的訊號。
更深層的問題是：如果 AI 找漏洞的速度持續加快，而人類驗證的速度相對固定，未來所有缺乏活躍維護者的程式碼，都將面臨同樣的壓力。這不是 ISDN 驅動的問題，這是所有「沒有足夠人力後盾的舊程式碼」的問題。
業餘無線電的尾聲
AX.25 業餘無線電協議的案例尤其有趣。LWN.net 的討論中有人提到，userspace 的解決方案（如 Direwolf）早就存在，功能甚至比核心驅動更完整。核心層的 AX.25 實作，與其說是在被使用，不如說是在被遺忘。
移除它，或許才是真正的尊重——讓它乾淨地結束，而不是繼續成為 AI 掃描工具的靶場。
AI Bug Reports Are Killing Linux’s 30-Year-Old Drivers
An Unintended Consequence
AI-assisted security scanning was supposed to improve software quality. In the Linux kernel community, it is producing an outcome nobody planned for: the tools are surfacing bugs faster than human maintainers can evaluate them, and the collateral damage is a collection of drivers that have been quietly aging inside the kernel for three decades.
Andrew Lunn’s Proposal
In April 2026, prominent Linux maintainer Andrew Lunn proposed removing a set of long-dormant subsystems:
- The ISDN subsystem (Integrated Services Digital Network — 1990s dial-up technology)
- ISA and PCMCIA-era Ethernet drivers (3Com, AMD, SMSC, Cirrus Logic, Fujitsu, Xircom, and 8390-based families)
- Amateur radio protocols (AX.25, NET/ROM, ROSE)
- ATM protocols and drivers
The proposal targets approximately 27,646 lines of code. When Linus Torvalds merged the full batch, the total reached 138,000 lines removed.
Lunn’s stated reasoning: “These old drivers have not been much of a maintenance burden until recently. Now there are more newbies using AI and fuzzers to find issues, resulting in more work for maintainers.”
The Asymmetry Problem
The core issue is structural asymmetry: AI tools can scan tens of thousands of lines of code in seconds and surface theoretical vulnerabilities, but human maintainers need time and judgment to evaluate each report.
These legacy drivers aren’t particularly complex. But the hardware they support has largely vanished from the market. When an AI scanning tool flags a bug in the AX.25 amateur radio stack or the ISDN implementation, the maintainer faces an impossible position:
- No physical hardware to reproduce the issue on
- No way to assess whether the vulnerability has any real-world attack surface
- No option to simply ignore it — what if it’s genuine?
Each AI-generated report becomes mandatory unpaid homework. Accumulated across enough reports, that becomes what Lunn called a “disproportionate burden.”
The Community Debate
The proposal sparked substantive discussion on LWN.net, the authoritative source covering Linux kernel development. Two lines of opposition emerged:
Industrial use cases: Some commenters noted that industrial and embedded systems have lifecycles measured in decades. Certain operational equipment genuinely depends on these protocols. Consumer hardware refreshes every few years; power plant SCADA systems might run unchanged for twenty.
The illusion of maintenance: A sharper critique pointed out that this code only appeared to be maintained because it was embedded inside Linux. As a standalone project, it would have been declared dead years ago for lack of updates. “It has been pretending to be maintained by being part of some large project.”
Lunn’s response was a buffer mechanism: any organization or individual willing to take genuine ownership of the code could keep it. Otherwise, it goes.
A New Kind of Reason to Die
Historically, kernel code gets removed because it’s unused or superseded by something better. This case is different — the trigger is external pressure generated by AI tooling.
This establishes a new logic: code can now be removed not just for being obsolete, but for attracting too much AI-generated noise. For anyone maintaining large open source projects, this is a signal worth taking seriously.
The deeper implication: if AI bug-finding continues to accelerate while human verification speed stays roughly constant, any codebase lacking active human stewardship will face the same pressure. This is not an ISDN problem. This is a problem for every piece of legacy code without enough people behind it.
The AX.25 Coda
The amateur radio case is worth a separate note. LWN.net discussion pointed out that userspace alternatives — notably Direwolf — already exist and are more capable than the kernel implementation. The in-kernel AX.25 stack wasn’t so much being used as being forgotten.
Removing it cleanly may be more respectful than leaving it as a target for automated scanners indefinitely.
參考來源：Kernel code removals driven by LLM-created security reports — LWN.net ／ Tom’s Hardware
發佈留言