Linux 内核中发现了若干漏洞

原文 ↗ Hacker News 讨论 ↗

一份列出 1,313 个 Linux 内核 CVE 的 Debian 安全公告，引发了关于这些数字对风险究竟意味着什么的争论，因为内核项目如今按照设计会为几乎任何修复都分配 CVE ID。评论者认为，这会夸大漏洞数量，并让维护者和管理员不堪重负；与此同时，AI 驱动的分析工具又发现了更多问题——其中许多都很冷门、影响有限，或只是误报。讨论在于，这波发现最终会让关键软件更安全，还是仅仅暴露出当前实践的结构性局限，从 C 语言内核到 CVE 评分和补丁管理皆是如此。

漏洞的规模与性质

  • 线程里提到 Debian 的一份安全公告中列出了约 1,313 个 Linux 内核 CVE；几位评论者开玩笑说，标题应写成“军团”而不是“若干”。
  • 许多人强调，这在很大程度上是流程变化的结果：内核项目现在会为几乎任何修复都分配 CVE，因为“几乎任何 bug 都可能被利用”。
  • 列出的很多问题都出现在驱动、文件系统或较冷门的子系统中，需要特定硬件或配置才能触发。

CVE 流程、含义与指标

  • Linux 已成为自己的 CVE 编号机构，如今对稳定版内核的回移植修复也会常规性地获得 CVE，而且往往带有保守甚至夸大的 CVSS 分数。
  • 有人认为，“CVE 数量”现在已经成了无用、甚至误导性的安全指标，尤其是对内核而言。
  • 讨论集中在什么算漏洞、什么只是“一个 bug”，以及几乎任何 bug 是否都能被包装成拒绝服务。
  • 一些人把这种大规模分配视为“恶意服从”，或是对早先低报问题的反作用；另一些人则认为这是必要的透明度，迫使用户自己做风险评估。

严重性、可利用性与分诊

  • 评论者指出，真正高严重性或可远程利用的问题很少；很多都需要本地访问、特定驱动或用户命名空间。
  • 管理员表示，他们已经不可能现实地逐个阅读并分诊每个内核 CVE；与其分析，不如直接全部打补丁更便宜。
  • 也有人反驳：频繁的内核更新和重启在运维上代价很高，尤其是对遗留系统和裸机工作负载。

AI 在发现与修复中的作用

  • 许多人认为，基于 LLM 的工具正在推动发现数量激增，尤其是在 2025–2026 年。
  • 来自内核演讲的报告显示：AI 工具确实能找到真实 bug，但误报率很高（通常超过 20%），而且很多都是隐蔽的边缘情况。
  • AI 被赞赏为强大的审查者和模式匹配器，尤其擅长串联细微 bug；但如果天真地使用，或用于批量提交低质量报告，也会被批评为“AI 垃圾”。
  • 有些人预见会经历一段很长的 bug 发现“海啸”，随后进入一个低垂果实更少的未来；也有人认为，模型的改进会让新问题被持续挖掘出来。

更广泛的安全反思

  • 讨论还涉及更安全的语言（Rust、Ada/SPARK）、形式化验证、微内核（seL4、QNX）以及隔离（VM、Qubes OS）等，认为这些比追逐每一个内核 bug 更根本。
  • 普遍共识是，完美安全不可实现；重点应转向遏制、分层防御，以及务实的补丁策略。