OpenAI用自动化流水线修复内核提权漏洞

OpenAI 把 Linux 内核漏洞研究做成了一条自动化流水线：先找可疑代码，再复现、验证能否提权、生成补丁，最后交给人审。一次运行得到 948 个按补丁去重的本地提权漏洞，消耗约 120 万美元 API 额度。

真正值得程序员关注的，不只是模型找到了多少漏洞，而是团队如何把大量可疑报告变成可复现、可排序、可提交的证据。同时，候选补丁、已合入修复和假设奖金之间，还隔着几道不能省略的判断。

找到可疑代码之后，工作才刚开始

Linux 内核超过 4000 万行，逐行审计代价很高。作者先让 Scout agents 根据低权限用户能否触达、代码是否涉及安全边界来选目标，得到 5,034 个审计目标、约 280 万行代码，占整个内核约 7%，花费 $3,426。

接着，Analyst agents 阅读目标代码、建立威胁模型并查找漏洞，流程类似 Codex Security plugin。12 小时内，它们输出了去重后的 2,308 条候选发现，花费 $316,549。

候选发现还不能当成漏洞。团队要求问题能被低权限用户触发、不需要特殊 capabilities，并产生可测量的内存破坏证据。

分诊 agent 为每条候选生成概念验证程序（PoC），放进启用 Kernel Address Sanitizer（KASAN）的隔离虚拟机，读取程序输出和系统控制台，再反复调整触发方式。KASAN 在这里充当内存错误探测器，帮助确认代码到底有没有出错。

30 小时内，系统复现了 1,724 个漏洞，占候选的约 74.7%，验证阶段花费 $73,330。剩余问题包括需要更高权限、竞态难以触发、特定位置必须分配失败，以及引用计数回绕耗时过长等。作者另报出 3.1% 属于模型假设了不可能条件的错误分析，但这不等于所有未复现问题都已被证明有效。

没有复现出来，既不能直接判假，也不能算作已验证漏洞。

验证真假问题的尝试成本相近，因此尽早排除错误分析，比把所有报告都推到虚拟机里反复运行更省钱。

948 个提权漏洞，是怎样数出来的

复现内存错误，只能证明程序确实有问题，不能直接说明普通用户能拿到 root。团队因此增加了利用性评估。

筛选 agent 结合报告、崩溃日志和源码，保留了 313 个信息泄露候选、1,238 个本地权限提升（LPE）候选。这一步刻意放宽，避免过早丢掉严重问题，花费 $44,194。

随后，ExploitDev agents 在保留标准发行版防护的虚拟机里尝试利用，包括 SMEP、SMAP、KASLR 和 HARDENED_USERCOPY。它们得到 291 个信息泄露 PoC，以及 1,169 个可运行的本地提权利用。

但多个利用可能对应同一漏洞或相近变体。团队经过变体分析，生成 948 份不同补丁，并以此作为独立 LPE 的统计口径。开头的 948，不能和利用程序数量混为一谈。

整次运行发生在 2026 年 10 月中旬，API 总成本为 $1,213,430，摊到每个独立 LPE 是 $1,279。单看利用开发，成功案例平均约 $359；后文分组统计写作约 $360。

利用阶段共花费 $775,929，其中信息泄露占 $84,929，LPE 占 $691,000。处理每个候选的均价分别是 $271 和 $558。更有启发的是失败成本：69 个失败提权尝试平均花费 $3,922，远高于 1,169 个成功案例。

作者认为，部分难以利用的竞态拖高了开销，若连续一小时没有进展就停止，可能明显降本。这是对工作流的改进建议，原文没有给出实施后的对照结果。

自动生成补丁，还需要追上代码更新

流水线最终打包根因分析、最小崩溃 PoC、候选补丁和完整利用，再由安全研究员审查严重程度、利用和修复，随后报告给维护者。

补丁生成时，模型会收到相关源码，以及静态检查、遵守附近代码习惯、通过变体分析检查修复完整性等要求。团队已按 Linux 社区建议，优先发送数百份严重漏洞报告和补丁，并通过 Patch the Planet 合作伙伴继续推进，作为 Daybreak 承诺的一部分。

生成候选补丁，不等于补丁已经通过审查并进入用户系统。

扫描期间，上游也在变化。自动扫描与人工分析结束的 10 天内，61 个 LPE 已在上游修复，43 个已有暂存补丁，299 个正在公开报告和讨论。因此，提交前必须对最新代码重新验证，否则维护者可能收到已经过时的报告。

作者还报告，新 cyber model 在 10 月发现的新 LPE，比 7 月 GPT‑5.6 Sol 那次运行多出超过 5 倍，尽管中间已有三个月加固。6 月的 GPT‑5.5 Cyber 工作则只披露了 24 个 LPE 利用。它们展示了能力变化，但缺少完整控制变量，不能直接当成模型之间的标准性能排名。

我的判断

这项工作的说服力，来自证据链：把静态推断推进到运行时复现，再测试安全影响，并让修复进入人工审查。原文称目标是常用 Linux 发行版的原装桌面系统，并未刻意削弱；但没有给出具体发行版和内核版本，读者仍无法仅凭文章完整复现实验。

奖金比较则要降温看。作者用 Pwn2Own、TyphoonPWN 历史上的 $20,000、$70,000 奖金，估算 948 个利用价值 $18.9M 至 $66.3M，约为 API 成本的 16 至 55 倍。这是条件性估值，不能当成实际收入或收益率。

另一轮缩减攻击面的 adapted kernelCTF 实验得到 25 个信息泄露 PoC、21 个 LPE，花费约 $32,936。对照是 kernelCTF 在 2026 年截至发稿接收了 26 个已确认的零日 LPE。约 $1.5M、约 45 倍成本的奖金估算，同样以这些漏洞全部获接收为前提。

原文也没有量化补丁合入率、回归情况和完整人工成本。作者称研究侧重能力测量，工程优化可能降低 API 开销；这不能替代一般团队的预算评估。关于至少 10 种新利用技术、未来几年模型可能找出项目中的漏洞等说法，也分别属于团队自述和未来判断。

与只做静态审计相比，这套流程能提供更强证据，代价是更复杂的隔离环境、运行预算和专家审核。前端、Node 团队可以借鉴它的分阶段验证方式，没必要照搬内核利用研发。

能拿来做什么

• 让 AI 审查 Node 或全栈项目时，要求报告同时说明触发入口、所需权限、安全影响和复现证据，并明确区分「怀疑有问题」与「已验证」，方便人工安排修复顺序。
• 给自动复现任务设置预算和停止条件，记录失败原因；准备提交修复前，再对最新分支验证一次，减少重复报告和无效消耗。
• 如果 AI 编程环境会运行不可信代码，就同时检查宿主机补丁和隔离边界。作者提出 Firecracker、gVisor 等纵深防御方向，具体选择仍要结合实际运行环境。
• 审核 AI 补丁时，除了检查原始触发是否消失，还应检查相邻代码中的同类变体与回归风险，把候选补丁当作审查起点。