数字在涨,但不是内核变烂了
稳定版内核维护者 Greg Kroah-Hartman 在公开幻灯片里抛出数据: Linux 7.x 系列每版修复的 CVE 数量从 7.1 的逾千跳到 7.2 的逾 1500,7.3 极可能突破 2000。Tom's Hardware 与 Solidot 几乎同步引用,两个独立来源相互印证。
Kroah-Hartman 的因果解释更值得追问: Linux 内核并未变得更不安全,而是 AI 辅助安全检测工具大规模涌入,对着 4000 万行源码做自动扫描,把能翻出来的「低危」缺陷一股脑扔进 CVE 库和邮件列表。
维护者的真实困境:报告太多,人手不够
自动工具揪出更多 bug 听起来像好事。现实却是 Linux 内核的维护团队规模并未同步扩张,大量报告涌进 Bugzilla、邮件列表和 patchwork 后,真正需要维护者人工甄别、复现、修复的工作量跟着指数级放大。
内核网络子系统维护者 Jakub Kicinski 在相关讨论中直接用了「不堪重负」(completely overwhelmed)这样的措辞,Tom's Hardware 在标题里把这句话原样搬了出来。一个维护者要被大量机器生成的报告淹没,本身就是 AI 时代软件工程的新问题:检测能力增长的速度,远快过人类消化与决策能力的增长。
绝大多数新发现的 bug 属于低危级别,不是真正的安全炸弹。维护者却不得不挨个调查——这是 GPL 协作体系下维护者的法律责任,也是上游厂商与下游发行版的合规要求。每个报告都必须有人看过、给出反馈,否则会演变成对外披露口径上的麻烦。
7.3 已经在「砍代码」止血
Kroah-Hartman 的幻灯片与 Solidot 援引的材料显示,Linus Torvalds 与各子系统维护者已在 7.3 周期采取激进策略:直接移除「几乎无人使用」的旧驱动代码,以减少 AI 工具能扫描到的攻击面。
7.3 已经移除了一批旧的 SGI 和 IBM 驱动。理由很直白:这些历史悠久、贡献者稀少的代码,正被 AI 工具以超高效率翻出 bug,而维护者对这些老硬件并没有多少维护意愿,留着只会让「报告洪水」雪上加霜。
这是带有强烈工具理性色彩的选择: 与其投入人力去验证机器给出的成千上万条可疑报告,不如直接砍掉可能产出报告的代码。这种「减法维护」在 Linux 内核历史上相当罕见,某种程度上也是 AI 工具对开源协作模式的一次逆向倒逼。
反思:AI 检测真让世界更安全了吗
AI 辅助安全扫描工具的爆发,正在重塑所有大型开源项目的维护成本结构。一个原本可能十年没人翻出来的边界条件 bug,现在被 GPT 系或专用静态分析工具秒级扫出,自动生成 CVE、自动写邮件、自动追踪 patch 状态。短期看是「安全研究的民主化」,中长期看把维护成本推到了一个只有头部商业项目才能承受的水平。Linux 内核靠 LWN、SFC、Intel、Red Hat、华为等公司养着几十位全职维护者,才勉强接住 AI 工具的报告洪流。普通开源项目大概率会直接停摆。
Kroah-Hartman 把这组数据摆在公开幻灯片上,与其说是在示警,不如说是在提醒整个开源社区: 当 AI 把「找 bug」的成本压到几乎为零,「验证和修复 bug」反而成了新的瓶颈。我们需要的不仅是更强的检测模型,还有更强的 triage 工具、自动复现验证,以及愿意为开源基础设施持续买单的资金机制。否则 7.x 之后是 8.x,数字只会越来越大。
参考: