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 的观察也被描述为令人鼓舞但仅限于该领域。不妨把当前阶段视为一个繁忙的补丁季，而不是一个已经确定的趋势。