OpenAI用Codex加速Linux安全补丁回移，已修复149个CVE

Artem Dinaburg 2026年11月2日 open-source、linux、patch-the-planet 页面内容 我们必须在稳定性和安全性之间做出取舍吗？ 成千上万个已知 CVE 缺少稳定分支的修复 工程师和 AI 可以加速向后移植（backporting） 稳定的 Linux 发行版之所以缺少现有的安全修复，是因为将这些修复向后移植既耗时又往往是不被感激的工作。我们正在使用 Codex 把每个修复的向后移植流程从数天缩短到数小时，让负责补丁审查的人员能够快速为 Ubuntu Long Term Support、Fedora 和 Linux 内核等关键软件提交修复。截至 10 月 29 日，我们的项目已帮助将 149 个不同 CVE 的修复送入稳定的 Linux 内核版本，并向 Fedora 和 Ubuntu 软件包提交了若干修复。 将修复部署到较旧软件需要多个步骤，包括把修复适配到较旧的代码、检查依赖关系，以及确保修复没有引入新的 bug。仅一项任务（比如在一个有问题的提交中定位 bug）就可能需要一周甚至更长时间的努力，而没有人会看到或感激这些付出。 我们的 Codex 工作流减少了准备和审查修复所需的人力。除去针对具体项目的初始设置，准备和审查一个直接的向后移植大约需要 30 分钟的人力投入；更复杂的情况大约需要三个小时。该工作流采用双管齐下的方式：由 agent 执行识别缺失修复、适配补丁、汇集验证证据、运行测试和准备提交材料等活动，而工程师则审查补丁并将其提交给维护者。 这些估算只涵盖补丁的准备和审查；回归测试和维护者的接受仍然是必不可少的。但人力投入的减少使得一大类被忽视的安全工作变得切实可行。补丁积压量很大，但我们现在有了切实可行的方法来处理它。 软件有 bug，我们会尽可能地修复它们。修复最先发生的地方是软件的最新版本。不幸的是，这往往也是修复唯一发生的地方。 向后移植是指把修复从最新源代码带到较旧版本的过程。对于知名的大 bug，修复确实常常被迅速向后移植。但对于许多其他 bug，向后移植过程从未发生。原因很容易理解：软件打包往往由已经超负荷工作的志愿者完成，而向后移植是令人沮丧、不被感激的工作，几乎得不到认可或关注。对于由志愿者团队负责的开源项目来说，向后移植（可以理解地）优先级很低。正如 XFS 开发者 Dave Chinner 曾描述的那样，这项工作是“实际上的一份全职工作”，如果没有足够的资源，就干脆没人做。 缺少向后移植是个问题，因为几乎没有人会运行用当今代码变更 freshly 构建的最新最棒的软件版本。人们绝大多数更青睐打包在“长期稳定”发行版中的稍旧、经过更多测试的软件。例如，大约 95% 的 Ubuntu Linux 安装都是 Long Term Support（LTS）版本。查看 Debian popcon 中已安装的 Linux 内核软件包，绝大多数都基于较旧的稳定树： 图 1：一张由 Codex 生成的图表，展示了 Debian popcon 中近期安装的内核软件包。绝大多数（约 96%）是较旧的稳定版本，而不是最新的内核系列。 用户面临一个抉择：要么坚持使用稳定、熟悉但存在安全缺陷的软件版本，要么升级到修复了这些缺陷但引入了其他变更和新功能（他们可能并不想要）的较新版本。 许多人有意不升级到新版本；我认为这完全是合理且正常的终端用户行为。就在最近，我把我的 Mac 升级到了 macOS 27，结果用不了那台多年来一直工作良好的打印机（直到 Codex 写了一个新的兼容打印机驱动）。类似的情况实际上要求使用较旧的软件。 我们不应该被迫在稳定性和安全性之间做选择。 一群具备网络攻击能力的 AI agent 可以像热刀切黄油一样穿透由稳定的、已知存在漏洞的软件构成的网络。问题的规模之大，以至于你当前运行的软件很可能包含可被现代 AI agent 利用的未修复安全 bug。随着 AI 辅助的漏洞挖掘使识别旧代码中的漏洞变得更加容易，减少这一积压变得越来越重要。这不仅仅是理论上的问题。针对最新高关注度 bug CVE-2026-98432（Linux TCP 栈中一个可远程利用的严重缺陷）的修复，在上游被打补丁数周之后，仍未进入各发行版的内核。这个 bug 关注度足够高，很快会在所有地方得到修复。但更冷门 bug 的修复永远不会被向后移植。我在自己的沙箱逃逸研究中看到了这一点，而稳定软件中的一个旧漏洞被用作了最近披露的 OpenAI 黑客事件的一部分。 让我们量化一下缺失向后移植问题的规模。为便于计数，我们可以只限于那些已在最新版本中打补丁、但在稳定软件包中缺失的已知 bug（已分配 CVE）。在本例中，我们将考察 Linux 内核、Ubuntu 26.04 LTS 和 Debian 13 Stable。我并不是在单挑这些项目——它们都运营得非常好！我使用它们是因为它们有关于未修复 CVE 的文档和记录。其他项目缺乏这种透明度。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）