AI 漏洞挖掘“过载”：Linux 内核考虑清理遗留网络驱动，安全成本正被大模型重塑

在大模型加速进入安全领域之后，一个此前被忽视的系统性问题开始浮出水面：漏洞被发现的速度，正在超过社区的维护能力。

近期，围绕是否清理老旧网络驱动，Linux kernel community 内部展开讨论。导火索并非传统意义上的技术债，而是一个更具时代特征的变量——AI 驱动的漏洞挖掘能力，正在让“历史代码”成为持续输出风险的源头。

从“没人看”到“被 AI 全量扫描”：遗留代码的处境逆转

长期以来，Linux 内核中保留了大量面向 80～90 年代硬件的网络驱动：

• 早已停产的网卡设备
• 几乎无人使用的协议实现
• 缺乏活跃维护者的子系统

这些代码之所以能长期存在，一个重要原因是：缺乏审计资源。换句话说，“没人看”在某种程度上等价于“风险未被显性化”。

但随着 AI（尤其是基于大模型的代码分析工具）介入，这一前提被彻底打破：

• 静态分析 + LLM 推理可以覆盖大规模代码库
• 模式识别能力让潜在漏洞更容易被触发
• 自动化报告生成显著降低漏洞披露门槛

结果是：遗留驱动从“低关注模块”变成“漏洞高发区”。

AI 安全工具的“副作用”：漏洞供给激增

过去，漏洞发现通常受限于：

• 人力审计成本
• 专家经验门槛
• 时间投入

而现在，AI 工具正在改变这一供给曲线：

• 大模型可以理解复杂控制流与内存操作语义
• 自动生成 PoC（Proof of Concept）的能力逐步增强
• 多轮推理可以模拟攻击路径（类似 agent-based exploitation）

这使得漏洞挖掘从“手工业”走向“半自动化流水线”。

但问题也随之而来：

发现漏洞 ≠ 能够修复漏洞

对于缺乏维护者的老旧驱动而言，每一个新发现的漏洞，都会变成社区的额外负担。

删除 vs 维护：社区提出“按需保留”策略

在这一背景下，Linux 社区出现了一种更为激进但现实的提议：

• 对于无人维护、几乎无使用场景的旧驱动 → 直接移除
• 对于仍有企业依赖的硬件 → 由使用方承担维护责任

其核心逻辑可以概括为：

谁使用，谁维护；否则就从主干代码中剥离风险

这一策略背后，实际上是对“开源责任边界”的重新划分：

• 过去：社区尽可能兼容历史
• 现在：社区优先保障现代系统安全

技术视角：为什么旧驱动更容易被 AI“击穿”？

从工程角度看，这类遗留代码存在几个典型问题：

1. 内存安全设计落后

• 大量使用裸指针
• 缺乏边界检查
• 不符合现代安全编码规范

2. 与现代内核机制不兼容

• 未适配最新的内核安全特性（如 hardened allocator）
• 与当前网络栈存在接口不一致

3. 缺乏测试覆盖

• 没有持续集成（CI）
• 缺少 fuzzing 数据
• 无回归测试体系

而 AI 工具的优势恰恰在于：

• 快速扫描异常模式（pattern-based vulnerability detection）
• 推理潜在 exploit 路径
• 组合多点弱点形成攻击链

这使得老旧驱动在 AI 面前呈现出“高密度可利用面”。

对 AI 工程的启示：安全成本模型正在变化

这一事件对 AI 工程社区的意义，远不止于 Linux 内核本身。

它揭示了一个关键趋势：

AI 不仅改变了开发效率，也在重塑安全成本结构

具体体现在：

1. 漏洞发现成本下降

• 更多漏洞被暴露
• 安全问题从“稀缺”变为“过剩”

2. 漏洞修复成本上升（相对）

• 维护资源成为瓶颈
• 长尾系统难以覆盖

3. 系统设计需要“可删除性（deletability）”

未来系统需要考虑：

• 模块是否可以安全下线
• 是否存在明确的维护责任人
• 是否具备生命周期管理机制

更广泛的影响：从开源到企业系统

这一逻辑并不局限于 Linux：

在企业 AI 系统中，同样存在类似问题：

• 长期遗留的 prompt 模板
• 无人维护的 agent workflow
• 旧版本模型的兼容层

当 AI 能够自动审计这些系统时：

• 隐藏问题会被快速放大
• 技术债将以“安全风险”的形式显现

结语：AI 让“技术债”不再沉默

Linux 社区关于删除旧驱动的讨论，本质上反映的是一个更深层的变化：

在 AI 时代，代码不会被遗忘，只会被重新发现。

当漏洞挖掘能力被规模化之后，系统的每一段历史代码，都可能成为未来的攻击入口。

对于开发者而言，这意味着：

• “向后兼容”不再是无条件的美德
• “可维护性”需要覆盖整个生命周期
• “删除能力”正在成为系统设计的一部分

AI 提高了软件的上限，也放大了历史遗留问题的下限。而如何在两者之间取得平衡，将成为下一阶段 AI 工程与系统架构的重要课题。