Linux 7.3 预计修复超 2000 个 CVE，AI 扫描让内核维护者不堪重负

Linux 7.x 系列 CVE 修复量从 500 跃至 2000

Linux 内核每个版本修复的 CVE 漏洞数量正在快速上升。根据稳定版内核维护者 Greg Kroah-Hartman 制作的幻灯片，Linux 6.x 时代这一数字长期维持在约 500 个左右。进入 7.x 系列后，情况发生显著变化。Linux 7.0 时已超过 1000 个，Linux 7.2 则突破 1500 个。按照当前趋势，Linux 7.3 预计将超过 2000 个。

这一增长曲线清晰显示出加速态势。从 6.x 到 7.0，修复量直接翻倍；从 7.0 到 7.2，又增加了约 500 个。Linux 7.3 若按此节奏推进，很可能首次突破 2000 大关。这些数据并非猜测，而是直接来自 Greg Kroah-Hartman 的公开幻灯片。

数字变化反映了内核开发规模的扩大和代码量的增长，但更关键的驱动因素来自外部工具。维护者需要处理的不再是传统手动发现的漏洞，而是大量自动化扫描结果。这直接改变了以往的维护节奏。以前一个版本几百个 CVE 已属常态，现在数字翻了两番以上，工作量相应激增。

对中国开发者而言，这一趋势意味着上游内核补丁的更新频率和复杂度都在上升。国内许多基于 Linux 的发行版和设备厂商必须跟进这些修复，测试工作量随之增加。企业级用户尤其需要关注，因为内核稳定性直接影响服务器和嵌入式系统的可靠性。

这一跃升不是孤立事件。它标志着开源内核维护从人工主导转向工具辅助后的新阶段。后续版本如果继续保持这一增速，维护模型可能需要根本性调整。目前已知的是，7.3 将是第一个可能突破 2000 的版本，实际数字还需等待正式发布后确认。

AI 扫描发现的 bug 多数属于低危级别

漏洞数量激增的真实原因并非 Linux 内核本身安全性变差。Greg Kroah-Hartman 的幻灯片明确指出，大部分新增报告来自 AI 辅助安全检测工具对内核源代码的自动扫描。这些工具能快速遍历海量代码，找出潜在问题。

然而，AI 发现的 bug 多数属于低危级别。它们并不构成立即可被利用的高风险漏洞，而是潜在的代码缺陷或边缘情况。传统人工审计时，这些低危问题往往被忽略或优先级较低。现在自动化工具把它们全部挖了出来，导致报告总量急剧上升。

这一变化本质上是工具能力提升的结果。AI 扫描覆盖范围远超人力所能及，能处理旧代码中长期未被关注的部分。结果就是报告数量从数百跳到上千乃至两千，但其中真正需要紧急处理的严重漏洞比例并未同步增长。

对中国开源生态来说，这意味着安全评估不能只看 CVE 总数。企业需要建立更细致的漏洞分级机制，区分 AI 报告的低危项和真正的高危威胁。否则容易陷入疲于应付低优先级问题的局面，分散对核心安全的注意力。

开发者工作流也受此影响。过去代码提交后主要关注功能和性能，现在必须额外考虑是否会触发 AI 扫描的警告。静态分析工具在 CI/CD 流程中的权重上升，代码审查标准随之提高。这对国内高校和企业的开源贡献者提出了新要求，他们需要熟悉这些自动化检测逻辑。

目前还不清楚 AI 工具的假阳性率具体有多高。但从维护者反馈看，大量报告确实属于低危，这解释了为什么 CVE 数字上升如此之快，却没有对应出现大规模安全事件。

维护者被 AI 报告淹没耗时筛选有效信息

内核维护者正面临前所未有的报告洪流。AI 工具生成的大量 bug 报告需要人工逐一审查，以判断哪些真正值得修复，哪些可以忽略。整个过程耗费大量精力和时间。

内核网络系统维护者 Jakub Kicinski 明确表示，他们有点不堪重负了。网络子系统代码量庞大，AI 扫描后产生的报告数量远超以往处理能力。维护者必须在有限时间内完成 triage（分类）、验证和修复，这直接压缩了开发新功能的时间。

工作负担加重体现在多个层面。首先是阅读报告本身。许多报告格式类似，需要仔细区分真实 bug 和工具误报。其次是复现和测试。低危 bug 往往只在特定硬件或老旧配置下触发，验证成本高。最后是上游沟通和补丁合并，整个流程被拉长。

对中国开发者而言，这意味着参与上游内核开发时，需要承担更多审查工作。国内企业如果向内核提交驱动或补丁，必须提前做好被 AI 工具反复扫描的准备。否则补丁可能因触发新报告而被反复打回。

这一负担还传导到下游。基于 Linux 的国产操作系统和芯片厂商，需要同步跟进上游 CVE 修复。维护团队规模有限的公司可能难以承受，迫使他们考虑商业支持服务或自动化辅助工具。

目前维护者主要依靠人工筛选。Jakub Kicinski 的表态反映了行业普遍感受：AI 带来了更多可见 bug，却没有相应提供足够自动化手段来消化这些信息。人力瓶颈已开始显现。

Linux 7.3 移除 SGI 和 IBM 旧驱动减少报告

面对报告激增，内核团队开始采取实际措施。Linux 7.3 移除了大量旧的 SGI 和 IBM 驱动代码。这些历史悠久的驱动基本上已无人使用，却被 AI 工具发现了大量 bug。

移除的目的很明确：减少维护成本。维护者有义务调查和修复 AI 报告的每一个 bug，即使这些代码几乎没有实际部署。删除它们能直接切断报告来源，减轻整体负担。

这一行动针对的是“死代码”。SGI 和 IBM 的老旧硬件驱动在现代系统中使用率极低，却占据代码空间并持续产生 AI 扫描噪音。清理后，未来版本的 CVE 报告数量有望得到一定控制。

对中国开发者来说，这一变化影响有限。大多数国内项目并不依赖这些古老的 SGI 或 IBM 特定驱动。但它传递出一个信号：内核正在主动瘦身，优先保留活跃代码。这可能鼓励更多厂商贡献现代硬件驱动，同时加速淘汰旧有支持。

移除行动也反映了维护策略的转变。从“尽量支持一切”转向“只维护真正被使用的部分”。这一思路如果持续，可能在后续版本扩展到其他子系统，进一步降低 AI 报告总量。

目前 7.3 中移除的具体驱动列表已在内核邮件列表中讨论。实际效果需要等版本发布后，通过 Greg Kroah-Hartman 的下一份幻灯片观察 CVE 数字是否有所回落。

中国开发者将面临更频繁的代码审查与 triage

Linux 内核 CVE 数量激增对中国开源生态构成直接压力。国内大量企业依赖 Linux 构建服务器、手机、汽车和物联网设备。上游修复量翻倍意味着下游同步更新周期缩短，测试和集成工作量显著增加。

开发者工作流需要调整。过去代码审查主要关注功能正确性，现在必须增加安全 triage 环节。AI 扫描工具很可能被引入企业内部 CI 流程，导致补丁被更多低危警告阻挡。开发者需要学习如何快速判断和修复这些 AI 报告，否则贡献上游的效率会下降。

安全策略层面，建议从单纯追踪 CVE 总数转向重视漏洞严重程度分级。政府和企业可推动建立统一的 AI 辅助漏洞评估标准，避免把过多精力消耗在低危项上。同时，加强对国产芯片和操作系统内核分支的安全加固，减少对上游主线版本的完全依赖。

开源社区方面，国内维护者可能需要组建专门的 triage 小组，集中处理 AI 报告。这既能分担上游压力，也能培养更多熟悉内核安全的人才。但人力成本会上升，中小型公司可能面临挑战。

整体看，这一趋势倒逼中国开源生态提升自动化能力和人才储备。长期而言有利于安全水平提高，但短期内会增加开发成本和工作节奏压力。企业需要重新评估内核维护在预算中的占比。

未来维护或转向 AI 辅助报告筛选机制

内核维护模式面临转型压力。当前主要依靠人工筛选 AI 报告的做法已难以为继。未来可能转向 AI 辅助的报告筛选和优先级排序机制，让机器先过滤掉明显低价值项，再由人工处理高优先级 bug。

这一方向目前尚未定论。Greg Kroah-Hartman 的幻灯片和 Jakub Kicinski 的表态都指出了问题，但尚未提出成熟解决方案。社区讨论中，有人建议改进 AI 工具本身的准确率，降低假阳性；也有人主张进一步清理死代码，从源头减少报告。

对中国而言，如果上游转向 AI 辅助 triage，国内项目可以同步采用类似工具。这能降低人工成本，但需要投入资源训练或微调模型以适应中文文档和国内硬件场景。目前还不清楚这类机制何时能落地。

展望来看，维护者可能不再追求修复所有 AI 发现的 bug，而是聚焦真正影响用户安全的部分。这会让 CVE 数字增长趋缓，但也要求社区重新定义“维护责任”的边界。

无论如何，AI 已深度介入内核安全流程。它既是发现 bug 的利器，也是制造工作量的来源。如何平衡二者，将决定 Linux 内核未来几年的维护效率。中国开发者作为重要参与方，需要及早跟踪这一演变并调整自身策略。

参考来源