稳定的 Linux 发行版缺少现有的安全修复，因为回移这些修复既耗时又往往是不被感谢的工作。我们正在使用 Codex 将每个修复的回移流程时间从数天缩短到数小时，使人工补丁审核者能够快速为 Ubuntu 长期支持版、Fedora 和 Linux 内核等关键软件提交修复。截至 10 月 29 日，我们的项目已帮助向稳定的 Linux 内核版本交付了针对 149 个不同 CVE 的修复，并向 Fedora 和 Ubuntu 软件包交付了 若干 修复。 将修复部署到较旧软件需要多个步骤，包括将修复适配到较旧代码、检查依赖关系，以及确保修复没有引入新错误。单个任务（例如在不良提交中追踪一个错误）可能需要
一周或更长时间 的努力，而没有人看到或感激这些工作。 我们的 Codex 工作流程减少了准备和审核修复所需的人工投入。排除项目特定的初始设置，准备和审核一个简单的回移大约需要 30 分钟的人工注意力；更复杂的情况可能需要大约三个小时。该工作流程的方法分为两方面：智能体执行识别缺失修复、适配补丁、组装验证证据、运行测试和准备提交材料等活动，而工程师则审核补丁并将其提交给维护者。
这些估计仅涵盖补丁准备和审核；回归测试和维护者接受仍然至关重要。但减少的人工投入使得一大类被忽视的安全工作变得切实可行。补丁积压量很大，但我们现在有了切实可行的方法来处理它。
我们必须在稳定性和安全性之间做出选择吗？
软件有错误，我们会在可能的时候尝试修复它们。修复首先发生在软件的最新版本中。不幸的是，这往往也是修复发生的
唯一 地方。 回移是将修复从最新源代码移植到较旧版本的过程。针对知名关键错误的修复确实往往会被快速回移。但对于许多其他错误，回移过程从未发生。原因很容易理解：软件打包通常由已经超负荷工作的志愿者完成，而回移是令人沮丧、不被感谢的工作，几乎得不到认可或关注。对于由志愿者团队运营的开源项目来说，回移（可以理解地）优先级很低。正如 XFS 开发者 Dave Chinner 曾经描述的那样，这项工作“
实际上是一份全职工作”，在没有足够资源的情况下就是没人去做。缺乏回移是一个问题，因为几乎没有人运行用当今代码更改 freshly 构建的最新最好版本的软件。人们
绝大多数 更喜欢打包在“长期稳定”版本中的稍旧、经过更多测试的软件。例如， 大约 95% 的 Ubuntu Linux 安装是长期支持（LTS）版本。查看 Debian 的 popcon 中已安装的 Linux 内核软件包时，绝大多数基于较旧的稳定树：图 1：Codex 生成的 Debian popcon 中最近安装的内核软件包图表。绝大多数（约 96%）是较旧的稳定版本，而不是最新的内核系列。
许多人
故意 不更新到新版本；我认为这完全是合理且正常的最终用户行为。就在最近，我将 Mac 更新到 macOS 27，却无法使用多年来一直完美工作的打印机（直到 Codex 编写了一个新的兼容打印机驱动程序）。类似情况实际上需要使用较旧的软件。 我们不应该不得不在稳定性和安全性之间做出选择。
数千个已知 CVE 缺少稳定分支修复
一群具备网络能力的 AI 智能体可以像热刀切黄油一样穿透一个由稳定的、已知存在漏洞的软件组成的网络。问题的规模如此之大，以至于你当前运行的软件很可能包含可被现代 AI 智能体利用的未修复安全漏洞。随着 AI 辅助的错误搜寻使识别旧代码中的漏洞变得更加容易，减少这一积压变得越来越重要。这不仅仅是理论上的。针对最新高关注度错误
CVE-2026-98432 （Linux TCP 协议栈中的一个严重远程可利用缺陷）的修复，在上游修补数周后仍未进入发行版内核。这个错误足够高关注度，很快会在所有地方得到修复。但更 obscure 错误的修复永远不会被回移。我在我的 沙箱逃逸研究 中看到了这一点，并且稳定软件中的一个旧漏洞被用作最近披露的 OpenAI 黑客事件 的一部分。.
让我们量化缺失回移问题的规模。为了简化计数，我们可以仅限于已知错误（已分配 CVE），这些错误在最新版本中已修补但在稳定软件包中缺失。在这个例子中，我们将查看 Linux 内核、Ubuntu 26.04 LTS 和 Debian 13 Stable。我并不是在单独指责这些项目——它们都运行得非常好！我使用它们是因为它们有关于未修复 CVE 的文档和记录。其他项目缺乏这种透明度。
让我们按稳定分支查看 Linux 内核中未解决的 CVE 数量。下表显示了每个受支持稳定分支中在该分支没有修复、但在较新分支中有修复的 CVE。（因此，按定义，较旧分支有更多未修复的 CVE。）来源是 内核 CVE 团队的 vulns.git ，截至 2026 年 9 月 18 日。这不是精确的错误计数，因为由于若干技术细节，它既会多计也会少计。它也不是可利用性的衡量标准。相反，它是一个衡量标准，表明大量已知 CVE 尚未在稳定内核分支中修复：
| 分支 | 未修复 CVE | 具有 NVD 评分的 CVE 百分比 | 高或严重 |
|---|---|---|---|
| 5.10.y | 2,006 | 55.8% | 213 (19.0%) |
| 5.15.y | 1,889 | 51.5% | 195 (20.0%) |
| 6.1.y | 1,329 | 43.9% | 99 (17.0%) |
| 6.6.y | 1,012 | 35.6% | 65 (18.1%) |
| 6.12.y | 686 | 22.3% | 21 (13.7%) |
| 6.18.y | 337 | 15.1% | 3 (5.9%) |
软件包方面的情况也好不到哪里去。以下是在 Debian 13 和 Ubuntu 26.04 中被报告为未修复或受影响的非内核 CVE（原始数据来自它们 各自的 批量 CVE 数据源，由 Codex 汇编）。这些是发行版元数据层面的发现，并非逐个经源码确认的漏洞。再次说明，这并非精确的缺陷计数，而更像是一把衡量标尺，用来表明稳定软件包中仍有多少未修复的漏洞：
| 发行版 | 存在未修复 CVE 的源码包 | 唯一 CVE 数 | 高或严重 |
|---|---|---|---|
| Debian 13 | 1,128 | 4,562 | 1,822 (39.9%) |
| Ubuntu 26.04 | 1,028 | 770 | 335 (43.5%) |
工程师和 AI 可以加速回移
我们意识到这是一个问题，并一直在主动修复。首先，我们从相当于在人行道上捡钱的事情做起：有些针对已知 CVE 的缺陷修复可以干净地应用到稳定内核树上，但修复从未被拉入内核。我们使用 Codex 配合 GPT-5.6 找到这些修复，并请维护者应用现有补丁。他们很慷慨地照做了。随后我们转向回移那些无法原样应用的补丁，从最容易验证和审查的开始，正缓慢推进到更复杂的改动。到目前为止，稳定树中已应用 149 个 CVE 修复； 我们回移跟踪器上的列表还在不断增长.
我们对 Linux 发行版也做了同样的事：我们使用 Codex 和 GPT-5.6 识别已发布稳定软件包中的已知漏洞，然后回移并验证修复。我们已开始带着首批补丁联系各 Linux 发行版。
如果你运营一个开源项目或 Linux 发行版，并希望获得回移安全修复方面的帮助，请在 trailofbits.com/patch-the-planet 申请，我们将很乐意提供协助。
不增加功能的稳定软件的一大优势在于，理论上我们可以在攻击者利用漏洞之前修复它们。所以，让我们继续修补这个星球吧！