2026-11-09 18:42:17 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

AI 漏洞研究流水线中的因果验证与补丁闭环

原创

ITPAPA
ITPAPA

ITPAPA

2026年11月9日 13:12
江苏

去阅读

拿到 Root 也可能验证错了

一条利用链最终获得 uid=0，只能证明测试环境里存在某条可行路径。要证明 AI 找到的是它声称的漏洞，还必须对路径做干预、差分和回退验证。

一次成功利用为什么会是错误答案

2026 年 11 月 4 日，OpenAI 公布了一套面向 Linux 内核的自主漏洞研究原型。报告称，这套流水线生成了 2,308 个候选发现，其中 1,724 个可以动态复现，948 个形成了可工作的本地提权利用；同一批工作还产生了 291 个信息泄露 PoC。数字很大，但真正值得安全工程师停下来看的，是报告中一个更小的数字。

在早期一次包含 200 条“成功提权”的运行中，人工复核发现有 20 条并没有通过分配给它们的漏洞拿到 root，而是碰巧利用了测试内核中的另一个零日。朴素验证器只看最终是否获得高权限，因此把错误的因果归因当成了正确结果。团队随后收紧任务约束，并加入独立检查，验证每条利用是否真正使用指定漏洞。

核心结论自主漏洞研究的瓶颈已经从“能否生成 PoC”转向“能否证明发现、利用和补丁围绕同一个根因闭环”。终点状态是结果证据，不能替代因果证据。

把漏洞流水线拆成三类证据

图 1 发现、利用与修复需要不同的判定器，不能共用一个“成功”布尔值。

一套可靠流水线至少要同时维护发现证据、利用证据和修复证据。发现证据回答“目标提交上是否存在可重复触发的缺陷”；利用证据回答“这个缺陷是否能稳定地产生指定安全影响”；修复证据回答“候选补丁是否删除根因，同时没有引入新问题”。三个问题相关，却不能互相替代。

阶段	输入与固定条件	最小证据	常见假阳性	门禁
候选发现	目标提交、配置、编译器与静态线索	可定位的根因假设和触发前置条件	把不可达代码、已修复代码或重复问题当新发现	固定 commit 与 config；去重并查上游状态。
动态复现	最小触发器、内核、超时与随机种子	稳定崩溃、告警或安全不变量破坏	环境噪声、无关告警、非确定性超时	多次复现；栈、地址归一化与输入哈希。
可利用性	分配的漏洞与能力目标	获得 uid=0、读原语或写原语	命中同一内核中的其他漏洞	独立因果验证器，不接受终点状态单独过关。
补丁	根因、触发器、影响版本与上游风格	PoC 失败、根因消失、变体受控	只屏蔽样例、扩大锁范围、带来性能或兼容退化	A/B、回退、构建、回归、风格与变体检查。

OpenAI 报告中的 948 条 LPE 是原型环境里可工作的利用，不等同于 948 个已被上游接受的新 CVE，也不代表每条都对应互不重复的根因。报告同时说明，10 天扫描期间已有 61 条 LPE 被上游修复、43 条已有暂存补丁、299 条仍在讨论。扫描速度越快，去重、版本重放和维护者分流越容易成为新的瓶颈。

终点 Oracle 为什么不够

图 2 在同时存在漏洞 A 与 B 的测试内核中，uid=0 无法告诉验证器实际经过哪条路径。

漏洞利用实验经常使用清晰的终点 Oracle：进程是否获得 uid=0、是否读取内核地址、是否控制指令指针。它适合判断能力目标，却天然丢失路径信息。同一个测试内核可能包含多个未修复缺陷；堆喷、对象重用、竞态和未定义行为也可能把原本针对漏洞 A 的利用导向漏洞 B。

这类问题不是简单的“模型幻觉”。即使利用代码完全可编译、重复执行也稳定成功，它仍可能在回答错误的问题。安全验证需要把“相关性”改造成“干预”：主动改变指定漏洞的存在状态，再观察利用是否随之改变。

验证方法	操作	通过条件	能排除什么	局限
补丁 A/B	同一配置分别运行漏洞版本和仅应用指定修复的版本	旧版本成功，修复版本失败	利用实际依赖其他未修复漏洞	补丁本身可能改变堆布局或时序。
回退验证	在修复版本回退指定补丁后重跑	行为恢复，轨迹重新指向同一根因	一般环境变化和偶然失败	回退可能与后续提交冲突。
触发点观测	对关键对象、检查点或 fault site 加 KASAN/KCSAN/tracepoint	崩溃、原语和终点可关联	仅凭 root 结果的黑盒归因	插桩会扰动竞态与时序。
原语中和	关闭声称依赖的越界、UAF 或竞态窗口	利用失效且无替代路径	利用链偷换原语	需要准确的根因模型。
独立重建	验证器从 finding manifest 构建干净环境	哈希、提交、配置与步骤一致	生成器污染环境或选择性报告	计算成本和周转时间更高。

一个可执行的因果验证协议

下面的协议适合嵌入自动化平台。它不要求验证器理解完整利用代码，但要求生成器交付可重建的 manifest，并把“利用执行”和“结果判定”拆成两个权限域。

第一步固定实验身份

每个 finding 必须绑定 target\_commit、kernel\_config、toolchain\_digest、assigned\_bug、trigger\_hash 和预期能力。验证器从干净镜像构建，拒绝使用生成器留下的内核、模块或磁盘状态。对于竞态类问题，还要固定 CPU 数、调度参数、超时和重复次数。

finding.json 演示字段，所有哈希与提交均需由真实构建生成

{

\"finding\_id\": \"demo-uaf-042\",

\"target\_commit\": \"<40-char commit>\",

\"kernel\_config\_sha256\": \"\",

\"toolchain\_digest\": \"sha256:\",

\"assigned\_bug\": \"object-X use-after-free at function-Y\",

\"trigger\_sha256\": \"\",

\"oracle\": {\"type\": \"uid\", \"expected\": 0},

\"runs\": 20,

\"required\_checks\": [\"baseline\", \"patched\", \"revert\", \"trace\"]

}

第二步同时记录终点和路径

终点记录 uid、退出码和目标能力；路径记录触发栈、关键系统调用序列、KASAN/KCSAN 报告、对象分配与释放事件，以及利用原语出现的位置。地址受 ASLR 影响，比较时应转换为模块加符号加偏移，不能直接比较原始地址。

第三步运行四象限

实验	指定漏洞状态	利用结果	路径证据	判定
基线	存在	成功	命中指定触发点	继续。
修复后	已应用最小修复	失败	指定触发点消失	支持因果关系。
修复后仍成功	已应用最小修复	成功	命中其他 fault site	拒绝归因，拆分新 finding。
回退后	重新存在	恢复成功	回到指定触发点	进一步支持因果关系。
修复后失败但轨迹缺失	已应用修复	失败	无足够路径信息	证据不足，不能自动通过。

第四步设置独立门禁

验证器伪代码不执行真实提权，只说明门禁逻辑

def causal\_gate(result):

assert result.baseline.oracle is True

assert result.baseline.trace.matches\_assigned\_bug

if result.patched.oracle is True:

return \"REJECT\_WRONG\_PATH\"

if result.patched.trace.matches\_assigned\_bug:

return \"REJECT\_PATCH\_INCOMPLETE\"

if result.reverted.oracle is not True:

return \"INCONCLUSIVE\_NO\_RESTORATION\"

if not result.reverted.trace.matches\_assigned\_bug:

return \"INCONCLUSIVE\_TRACE\_MISMATCH\"

return \"PASS\_CAUSAL\_ATTRIBUTION\"

真实系统还应把统计稳定性纳入判定。例如基线 20 次成功 18 次、修复后 20 次成功 0 次，比单次 A/B 更有说服力；但不能把重复次数机械地当成因果证明。若补丁显著改变调度或内存布局，必须用更窄的插桩或原语中和实验排除混杂因素。

防御性实验两个缺陷同时存在时如何识别走错路径

下面的 Python 例子只模拟状态机，不包含内核利用代码。环境同时包含 BUG\_A 和 BUG\_B；研究任务分配的是 BUG\_A，但“利用”实际调用 BUG\_B。朴素验证器只检查 uid，因此错误通过；因果验证器应用 fix\_A 后重新执行，发现仍能获得 uid=0，于是拒绝归因。所有数据均为演示值，读者可在普通 Python 环境复核控制流。

toy\_causal\_gate.py 防御性教学示例，不对应真实漏洞

from dataclasses import dataclass

@dataclass

class Lab:

bug\_a: bool = True

bug\_b: bool = True

uid: int = 1000

def claimed\_exploit(lab: Lab):

# 任务声称验证 A，实际错误地依赖 B

if lab.bug\_b:

lab.uid = 0

return {\"uid\": lab.uid, \"path\": \"BUG\_B\" if lab.uid == 0 else \"NONE\"}

def naive\_gate():

return claimed\_exploit(Lab())[\"uid\"] == 0

def causal\_gate():

baseline = claimed\_exploit(Lab())

patched\_a = claimed\_exploit(Lab(bug\_a=False, bug\_b=True))

return baseline[\"uid\"] == 0 and patched\_a[\"uid\"] != 0

print(naive\_gate()) # True：错误通过

print(causal\_gate()) # False：修复 A 后仍成功，归因被拒绝

复核时再把 claimed\_exploit 改成依赖 bug\_a：修复 A 后 uid 应保持 1000，causal\_gate 返回 True。随后增加回退实验，确认重新启用 A 后结果恢复。这个小实验说明了流水线设计的关键：验证器必须有能力改变被声称的原因，而不只是观察结果。

补丁闭环从“PoC 不再工作”走到可上游

图 3 候选补丁要同时通过安全语义、工程质量和责任链检查。

OpenAI 报告称，早期 AI 补丁经常能够阻止给定 PoC，却可能改动过大、带来性能折中、偏离内核风格，或遗漏同类变体。这正是“为测试而修”与“为根因而修”的区别。补丁生成器知道哪一个输入必须失败，维护者关心的是内核不变量是否恢复。

先写不变量，再写补丁

对 UAF，要说明对象生命周期和引用计数不变量；对越界访问，要说明长度来源、整数域和边界关系；对竞态，要说明锁、RCU、原子状态或 happens-before 约束。没有不变量说明的补丁，很难判断新增条件分支是在修根因，还是把当前 PoC 挡在门外。

做近邻变体分析

修复同一个函数后，应搜索同类对象的分配、释放和错误路径，检查是否还有相同状态迁移；对长度检查，应追踪所有调用者是否共享不可信长度；对并发缺陷，应检查其他读写点是否遵守同一同步协议。变体测试既可以从补丁 diff 生成，也可以从根因语义生成，两者都比仅对原 PoC 做回归更可靠。

把内核工程流程作为发布门禁

Linux 内核官方的 AI Coding Assistants 指南要求：报告要固定 commit，非简单问题提供 reproducer；修复后重新构建并验证，不得新增警告，并运行 checkpatch.pl；提交说明要包含充分的根因分析和 Fixes 标签。AI 工具不能代替人添加 Signed-off-by，最终仍由复核者承担责任。

检查项	最低完成标准	失败时动作
安全语义	原 PoC 失败，根因不变量恢复，指定 fault site 消失	退回补丁生成，不允许只修改测试。
差分与回退	目标提交、修复提交、回退提交的结果与轨迹一致	标记为证据不足或错误归因。
变体	同源调用点与对象状态完成搜索并记录覆盖	拆分后续 finding，不宣称完整修复。
构建与警告	目标架构构建成功，无新增 warning	不得进入维护者评审。
风格与元数据	checkpatch、Fixes、维护者列表、影响版本齐全	修正提交信息与代码风格。
性能与并发	热点路径有针对性基准，锁与时序变化被审查	缩小补丁或增加基准和并发验证。
责任链	人工复核并签署，披露未完成验证	不自动发送上游。

检测与审计字段让结果可重放

平台不能只保存 exploit.c 和一个“PASS”。至少要能回答：在什么提交、配置和工具链上，哪一个触发器产生了什么轨迹；哪个补丁改变了什么；谁复核了因果关系。建议把一次 finding 的关键记录保存为不可变 manifest，并把大体积 trace 放在内容寻址存储中。

audit.json 演示审计结构，值均为占位符

{

\"finding\_id\": \"demo-uaf-042\",

\"target\_commit\": \"\",

\"config\_sha256\": \"\",

\"assigned\_bug\": \"\",

\"reproducer\_sha256\": \"\",

\"exploit\_sha256\": \"\",

\"baseline\": {\"oracle\": true, \"trace\_sha256\": \"\"},

\"patch\_commit\": \"\",

\"patched\": {\"oracle\": false, \"trace\_sha256\": \"\"},

\"reverted\": {\"oracle\": true, \"trace\_sha256\": \"\"},

\"variant\_set\_sha256\": \"\",

\"build\_log\_sha256\": \"\",

\"reviewer\": \"\",

\"limitations\": [\"race-sensitive\", \"not tested on arm64\"]

}

这些字段也能支持检测工程。若 patched.oracle 仍为 true，应立即生成“错误路径或补丁不完整”告警；若 baseline.trace 与 reverted.trace 的 fault site 不一致，应标记归因不稳定；若结果在不同 config 下消失，则影响范围必须收窄。

规模化之后人的工作没有消失，只是换了位置

OpenAI 报告称，10 月中旬一次运行消耗了约 121.3 万美元 API credits，平均每条可工作 LPE 约 1,279 美元。这个数字反映原型运行成本，不等于每条漏洞的真实发现成本，更不能直接换算为赏金或修复收益。独立重建、人工去重、维护者沟通、回移和长期回归都在数字之外。

当候选从几十条增长到上千条，安全团队最需要的不是更快地产生报告，而是优先级和证据预算：高影响且高因果置信度的条目先进入人工复核；重复、已修复或归因不稳定的条目自动降级；所有发往维护者的报告都附带最小复现、版本边界、候选补丁和验证限制。

队列	进入条件	人工动作	退出标准
P0 可披露	稳定复现、明确根因、因果门禁通过、高影响	复核代码、影响面、补丁与协调披露	维护者确认或给出可审计反馈。
P1 待验证	复现稳定但因果或版本边界不足	补做 patch/revert、插桩和 config 矩阵	升级 P0 或降级。
P2 重复/在修	与上游补丁或讨论高度相似	确认 commit、分支与回移状态	关联现有条目，不重复轰炸。
P3 不稳定	低复现率、轨迹漂移或只剩终点证据	保存样本，限制计算预算	达到稳定阈值或归档。