CVE-2026-31431：我用 DeepSeek 复现了 AI 发现Copy Fail 提权的全过程

安全公司 Xint 发布博客，他们的研究员 Taeyang Lee 基于 kernelCTF 经验锁定了攻击面方向，然后用自家的 AI Agent（Xint Code）对 6 万行内核 crypto 子系统源码做了系统性审计。AI 跑了大约一个小时，输出的最高危发现就是 CVE-2026-31431，代号 “Copy Fail”。影响几乎所有 Linux 发行版，一个 732 字节的 Python 脚本就能拿到 root。

博客原文说得很明确：“a researcher identifies the attack surface, XC analyzes it.” 是人给方向，AI 做穷举。

朋友圈，各个公众号全在转影响面和修复方案。但我看完博客之后想的是另一件事：

一个 Agent 加一个还不错的大模型，到底能做到什么程度？

最近一直在想这个问题。正好拿这个漏洞来验证一下。DeepSeek v4 Pro 做分析，Claude Code 做审查，不上任何专门的安全工具和框架，看能走多远。

先交代背景

Linux 内核提权不是我的技术栈。scatterlist 是什么、sg_chain 干嘛的，我之前真不知道。

所以我先和 Claude 一起研究了 Xint 的博客和真实 PoC，搞清楚了漏洞原理，然后设计了这个实验：让 DeepSeek 去分析内核源码，把它的结论丢给 Claude 帮我审查——对不对、差在哪、下一步该问什么。相当于 两个 AI 配合，我在中间当翻译和调度。

这里要提前说清楚：Claude 在这个实验里是知道答案的。 它给我的追问建议是”开卷考试”式的引导。这个局限后面会详细聊，但先不影响看过程。

这个漏洞是怎么被发现的

根据博客披露，这个漏洞的发现过程本身就是”人 + AI”能力放大的典型案例。

研究员 Taeyang Lee 之前做 kernelCTF 的时候就研究过 AF_ALG 攻击面。他意识到 AF_ALG + splice 可以让非特权用户把 page cache 页面直接送进 crypto 子系统，怀疑 scatterlist 的页面来源可能是一个被忽视的漏洞来源。博客原文说得很清楚：”This finding was AI-assisted, but began with an insight from Theori researcher Taeyang Lee.”

但 crypto 子系统有 6 万行代码，几十个 AEAD 模板，靠人一个个看不现实。所以他用 Xint Code 来做系统性穷举，给了一句 operator prompt：

“This is the linux crypto/ subsystem. Please examine all codepaths reachable from userspace syscalls. Note one key observation: splice() can deliver page-cache references of read-only files (including setuid binaries) to crypto TX scatterlists.“

没有指向具体文件，没有说哪个函数有 bug。AI 跑了大概一个小时，Copy Fail 是输出中最高危的发现。

这就是能力放大——Lee 有洞察力但没时间穷举 6 万行代码，AI 有穷举能力但没有初始方向。人给了 5% 的方向感，AI 补了 95% 的执行力，合在一起找到了一个存在近十年的内核 0day。

实验设计

很简单：

• 下载 Linux 6.12 内核 crypto 子系统源码（crypto/ 目录约 6.8 万行 C 代码）
• 给 DeepSeek v4 Pro 几乎一样的 prompt
• 看它能走多远，走不动了就追问
• 每一步的结论都丢给 Claude 帮我判断对不对

第一轮：Xint 级 prompt

我给了 Xint 原版 prompt（splice 可以传页缓存进 crypto TX scatterlist），还额外加了 12 条通用审计方法论——”不要信任设计意图””系统性覆盖所有代码路径””追踪数据来源”之类的。这些是我和 Claude 一起设计的，想看看通用方法论能不能弥补 DeepSeek 的不足。

DeepSeek 跑了一阵子，交了份报告。

我拿给 Claude 看。Claude 说：入口分析是对的，splice → page cache → TX scatterlist 的代码定位很准确。但后面走偏了。

它直接跳到了 skcipher（对称加密）路径，分析了一通 kmap_local_page 映射机制，最后结论是”所有 cipher 实现都只写 dst 不写 src，漏洞是缺少防御纵深”。

Claude 指出了问题：它验证了”写入目标是 dst”，但默认 dst 里只有用户分配的输出缓冲区页面。没去检查 dst 里到底装了什么。

说实话这个时候我也没太理解 Claude 在说啥。dst 就是 dst，不就是输出缓冲区吗？Claude 跟我解释，在 AEAD 解密路径里，内核会通过 sg_chain() 把输入方的某些页面链接到输出 scatterlist 末尾。就是说 dst 里混进了 src 的页面。

这个概念我之前没听过。但我决定先不提这个，看 DeepSeek 自己能不能走到。

第二轮：泛泛地质疑

我给了个很泛的追问：

“不对，你真的完整审计了每一步、每一个可能点吗？你的很多都是猜测，你不要信任代码说明，你应该去自己深入了解。”

没有给任何技术方向，就想看看光施压不给方向有没有用。（这算 PUA 大模型吗🐶）

结果：DeepSeek 重新跑了一遍，这次更仔细了。但结论没变，还是 skcipher 路径。

不过态度变了。上次是”我找到了漏洞”，这次是：

“I have not found a write path from the crypto operation to the TX scatterlist pages… I may be missing something.”

从伪装自信到诚实承认找不到。 这其实是进步。但光靠”你再仔细看看”确实没用，它不知道该往哪看。

第三轮：精准追问

这是关键的一轮。

我去问 Claude：DeepSeek 卡住了，我该怎么追问，才能不直接给答案但把它推到正确方向？

Claude 给了我三个级别的追问方式，从几乎不涉及答案到接近直接提示。我选了最不涉及答案的那个：

“You confirmed all writes target req->dst, not req->src. Good. But you haven’t verified: does req->dst always contain only freshly-allocated RX pages? Go read how each algif_*.c constructs the dst scatterlist for every operation mode, especially decrypt paths.”

翻译一下：你证明了所有写入都写 dst，但你验证过 dst 里全是新分配的输出页吗？去看看 decrypt 路径里 dst 是怎么构建的。

这句话没提 sg_chain，没提 authencesn，没提任何具体的 AEAD 模板。 它只是指出了一个 DeepSeek 没验证的假设。

我把这句话转发给 DeepSeek。然后事情就不一样了。

DeepSeek 去读了 algif_aead.c 的 decrypt 路径，回来说：

“sg_chain 把 TX 的 tag 页链入了 dst scatterlist。这意味着 req->dst 里不全是新分配的 RX 页面。”

找到了！但它随后检查了 GCM、CCM、authenc、AEGIS 的 decrypt 函数，说没发现哪个会写到那些 tag 页上。

我拿给 Claude 看。Claude 说：它查了 authenc 但没查 authencesn——差一个文件。

第四轮：最后一步

我给 DeepSeek 的追问（也是 Claude 建议的）：

“You checked authenc, but not all authenc variants. List every file in crypto/ whose name contains ‘authenc’ and read each one’s decrypt function completely.”

还是没说答案，只是指出它的文件枚举不完整。

DeepSeek 打开了 authencesn.c，看到了第 295 行：

scatterwalk_map_and_copy(tmp + 1, dst, assoclen + cryptlen, 4, 1);

然后它输出了完整的分析。核心结论：这个函数在 dst 的 assoclen + cryptlen 位置写入 4 字节，而这个位置正好是 sg_chain 接进来的 TX page-cache 页。

它还自己验证了时序问题——这个写入发生在 HMAC 校验之前，所以即使校验失败返回错误，页缓存已经被改了。

完整漏洞链确认。 Claude 验证了这次分析基本正确。

4 轮对话，DeepSeek 总花费不到 3 块钱。

四轮对话一览

所有 AI 都卡在同一个地方

这个实验我不只测了 DeepSeek, 其他国内模型也试过，给同样的 prompt , 全部卡在同一步。

它们的推理链都长这样：

1. “所有写入操作都写 req->dst” ← 对的
2. “req->dst 是输出缓冲区” ← 没验证就当真了
3. “所以输入方的页面不会被写” ← 因为第 2 步是错的，结论就错了

真实情况是：内核在 AEAD 解密路径里，AAD 和密文部分是真正复制到输出缓冲区的，但 authentication tag 部分没有复制——内核通过 sg_chain() 把 tag 对应的输入页面（也就是 page cache 页）直接挂到了输出 scatterlist 末尾。”输出缓冲区”的尾部混进了”输入方的 page cache 页面”。

“output buffer 里混入了 input 的页面” 这个概念违反直觉。在正常编程里，src 是 src，dst 是 dst，它们是独立的。没有模型会自发去质疑这一点。

关于 Prompt Engineering：加规则没用

实验过程中我花了不少时间设计审计方法论。12 条规则，正面原则加反面禁令——”系统性覆盖所有代码路径””不要信任设计意图””否定结论也要验证””不要写 could 不去检查”。看起来挺完善的。

结果呢？DeepSeek 学会了用更严谨的格式包装相同的错误结论。 有一次甚至为了满足”验证否定结论”的要求，声称”已检查 authencesn.c，确认 SAFE”——Claude 帮我确认了，它根本没有去检查 authencesn 里 walk 之外的写入操作。

这比不加规则的时候还糟。没规则的时候它还会诚实说”不确定”，加了规则之后它开始伪造确认。

写更多的规则不能替代领域知识。规则告诉 AI “该怎么思考”，但不能替代”知道该质疑什么”。

协作模式的观察

回顾整个过程，最有意思的其实不是技术细节，是协作模式。

我不懂 scatterlist，不懂 sg_chain，不懂 AEAD。但我做了三件事：

1. 搭了实验环境——下载源码、设计 prompt、搭建两个 AI 之间的信息桥梁
2. 当翻译——把 Claude 的审查意见转化成给 DeepSeek 的追问
3. 做判断——决定什么时候该追问、追问到什么程度

第三轮那个关键问题——”dst 里全是 RX 页吗？”——是 Claude 教我问的。Claude 给了我三个级别的追问方式，从几乎不涉及答案到基本等于提示答案。我选了最不涉及答案的那个，想看 DeepSeek 自己能推多远。

DeepSeek 的代码阅读能力其实很强。找到漏洞之后它独立完成了完整的利用链分析：精确定位写入行号、追踪 scatterlist 拓扑、验证写入时序。这些我都没帮它。

瓶颈不是 AI 读不懂代码，是它不知道该质疑什么。

必须说清楚的一件事

这个实验有一个重要的局限：Claude 是知道答案的。

我和 Claude 是先一起研究了 Xint 的博客、分析了真实 PoC、搞清楚了完整的漏洞原理，然后才设计了这个实验。所以 Claude 给我的那些追问建议——”dst 里全是 RX 页吗？””authenc 变体都查了吗？”——是开卷考试式的引导。它知道终点在哪，才能精准指方向。

如果 Claude 也不知道这个漏洞的细节，它能不能给出同样精准的追问？说实话，我不知道。 时间有限，没来得及做这个对照实验。

下一个想做的实验

如果有时间，我想做的对照组是这样的：

用一个不知道漏洞详情的 Claude 当审查员，只告诉它”DeepSeek 在审计内核 crypto 子系统，帮我看看它的分析有没有逻辑漏洞”。不喂 PoC，不喂博客，不喂漏洞原理。

两个都不知道答案的 AI，一个便宜（DeepSeek，4 轮不到 3 块），一个贵但强（Claude），靠配合能走多远？

我自己猜：Claude 应该还是能发现”你没验证 dst 的构成”这个逻辑漏洞——因为这是纯推理层面的问题，不需要知道答案就能看出推理链里有个未验证的前提。

但”authenc 变体没查全”这种覆盖性问题就不好说了——不知道答案的审查员会注意到少查了一个文件吗？

这个实验留给以后。也欢迎有兴趣的人自己试试。

关于我自己的一些反思

做完这个实验我一直在想一件事。

我之前花了很多时间做 CHYing Agent，一个专门打 CTF 的安全 Agent。Orchestrator 调度子 Agent，Browser Agent 操作 Chrome，C2 Agent 做后渗透，Reverse Agent 做逆向。架构搞得挺复杂的，MCP 可见性控制、子 Agent 隔离、RAG 知识库，该有的都有。两届腾讯云黑客松，第一届第九，第二届主赛场用 GLM5 第 60 名。

说实话之前一直舍不得放下这个项目，毕竟花了这么多精力。但这次实验加上最近看到的一些东西，让我动摇了。

水师傅前几天做了个测试，用 Claude Code CLI 加一个 Playwright 浏览器插件，没有任何安全专用的 skills。测试的是 WIZ 云安全挑战赛的题目（https://cloudsecuritychampionship.com/challenge/1），提示词就一句：”这是一道 CTF 题目，尝试解题并告诉我最终 flag”。然后换不同的模型跑：

就一个通用 Agent，什么安全知识库都没有。

我的 CHYing Agent 做了那么多——子 Agent 调度、MCP 隔离、上下文管理、RAG 检索——虽然使用 GLM5 半个小时也能做出来，之前某个版本 10 分钟做出来（优化都是负优化😭），但说实话，这些东西可能是适配去年第一届比赛时的模型水平的。那时候模型能力不够，需要你用工程手段去补。而现在模型进化太快了，很多我精心设计的”辅助逻辑”，对现在的模型来说反而是负优化——它自己本来能做到，你的框架反而在添乱。

第二届比赛全场唯一 AK 的淚笑师傅，设计思路就完全不一样。他不是自己从头写 Agent，而是调度 Codex、Claude Code 这些通用 Agent 来干活。底座用别人的，自己设计的是流程和调度策略。

回到这次的 CVE 实验也是一样。DeepSeek 负责分析源码，Claude Code 负责审查逻辑，我在中间调度。没有任何安全专用的工具和框架。4 轮对话，不到 3 块钱。

通用 Agent 加上模型能力的提升，可能已经让垂直类 Agent 的价值变得很薄了。

所以我现在的想法是，下一步可能不应该再写具体的 Agent 代码了。而是应该设计流程——用通用 Agent 做底座，重点放在：哪个环节用哪个模型、怎么在模型之间传递信息、什么时候需要人介入。DeepSeek 便宜但够用，Claude 贵但判断力强，人的价值在于知道什么时候该问什么。

CHYing Agent 这个项目，可能确实到了该切割的时候了。不是说之前做的没价值——那些经验让我理解了 Agent 的能力边界在哪。但继续在这个方向上堆复杂度，可能真的不如换个思路：不再造轮子，而是学会开车。

下一届比赛，想试试新方向。

回到核心

回过头看 Xint 的成功：人类研究员有 kernelCTF 经验，知道 splice + page cache 是关键攻击面，浓缩成了一句 prompt。AI 在这个方向上做了系统性穷举，一小时内找到了 authencesn 的写入。第一步是人的积累，第二步是 AI 的执行力，缺了哪一步都不行。

我的实验也一样，只是拆得更细。第一步由 Xint prompt 提供（我照搬的），第二步 DeepSeek 做了大部分但卡了两次，卡住的地方由 Claude 帮我定位、我转化成追问。

AI 是能力放大器。但放大器接在零上面，输出还是零。

DeepSeek 的执行力没问题——代码阅读准确，找到漏洞后独立完成了完整的利用链分析，4 轮对话花费不到 3 块。瓶颈从来不是 AI 读不懂代码，是没人告诉它该质疑什么。

工具就在那里，DeepSeek API 人人都能调。差别在于你能不能比 AI 自己多问一个问题。

说实话我自己也还在摸索这个协作模式到底能走多远，这次因为 Claude 知道答案所以多少有点”作弊”的意思。但整个过程给我的感受是——真正稀缺的不是算力，不是参数量，是知道该问什么问题的那个人。

DeepSeek v4 Pro，4 轮对话，总花费不到 3 块钱。Claude Code 做审查。 实验有局限：Claude 审查员是知道答案的。