Copy Fail如何证明人机协同能挖内核漏洞

Copy Fail展示了研究员定方向、AI做扫描的人机协同漏洞分析流程。

2026年3月23日，Theori 研究员 Taeyang Lee 向 Linux 内核安全团队提交了 CVE-2026-31431，也就是后来被称为 Copy Fail 的漏洞。这个漏洞的 CVSS 评分是 7.8，影响范围覆盖 Ubuntu 24.04 LTS、RHEL 8/9/10、Amazon Linux 2023 和 SUSE 16 等主流发行版，修复补丁在 4 月 1 日合入主分支，4 月 29 日公开披露。

这次发现真正重要的，不是漏洞本身

Copy Fail 之所以值得写，不只是因为它是一个 Linux 内核本地提权漏洞，而是因为它把“人类研究员 + AI 平台”的分工关系讲得非常清楚。这个漏洞不是 AI 自己撞出来的，也不是传统人工审计一行行翻出来的，而是研究员先提出一个很窄、很具体的攻击面假设，再让 AI 去做大范围语义扫描。

这个流程很像高手带着新工具打仗。人负责判断哪里值得看，AI 负责把相关代码路径尽量扫干净。对安全研究来说，这比“AI 自动发现漏洞”的叙事更现实，也更接近今天真正能落地的工作方式。

文章里提到的关键点很明确：Xint Code 在约 1 小时内完成了对 crypto 子系统的深度关联分析，定位到了 authencesn 模板中的逻辑缺陷。这个速度放在人工审计里，几乎不可能靠纯手工实现。

• 漏洞类型：逻辑缺陷，不是传统内存破坏
• 利用方式：100% 稳定的本地提权
• 攻击脚本：732 字节 Python
• 影响面：多个主流 Linux 发行版

研究员先定方向，AI 再放大结果

Taeyang Lee 的价值不在于“发现了一个奇怪的函数”，而在于他把 AF_ALG 套接字、splice() 零拷贝、scatterlist 这些看似分散的组件，串成了一个可疑的攻击面。他的直觉来自 kernelCTF 经验，也来自对内核加密子系统交互边界的长期观察。

这里最关键的一点是：研究员不是在问“crypto 子系统有没有 bug”，而是在问“AF_ALG + splice 能不能把只读页缓存送进一个最终会被写入的位置”。这个问题非常具体，AI 才有可能围绕它做有效搜索。没有这个方向，AI 只会在大量正常代码里来回跑。

“a researcher identifies the attack surface, XC analyzes it” — Xint Code

这句话很直白，也很准确。人类提供判断，AI 提供规模化执行。Copy Fail 的发现过程几乎就是这句话的注脚。

更重要的是，这种分工解决了一个老问题：复杂系统里的漏洞往往不是单点错误，而是几个“单独看都合理”的改动叠在一起之后，才出现的交互失配。Copy Fail 就是这样。

为什么传统方法很难碰到它

Copy Fail 不是那种会直接崩溃、冒日志、触发明显异常的漏洞。它的根因藏在三个时间点不同、目标不同的改动里：2011 年的 authencesn 实现，2015 年 AF_ALG 接口对非特权用户开放，2017 年的 in-place 优化。每一步单独看都说得通，合在一起却把页缓存写进了不该写的位置。

这也是为什么模糊测试、规则型静态分析、内存检测工具都不容易发现它。它不是越界读写那种“看一眼就知道不对劲”的问题，而是语义层面的错位：写入行为本身看起来合法，但合法的前提建立在错误的对象属性上。

如果把传统方法拆开看，局限会更明显。

• 模糊测试擅长找崩溃，不擅长找跨子系统语义错位
• ASan 和 KASan 盯的是内存安全，不是逻辑授权关系
• 规则型 SAST 依赖已知模式，碰到组合型缺陷就容易失效
• 人工审计能发现问题，但很难穷举 Linux 内核级别的全部交互路径

这也是 Copy Fail 最有意思的地方：它不是“更隐蔽的内存洞”，而是“更复杂的系统协同错误”。

数据、算力和经验，三者缺一都不行

文章把 Copy Fail 的出现放在 2026 年这个时间点，原因也很现实。第一，LLM 的语义理解能力已经到了能处理跨文件、跨模块关系的程度。第二，GPU 和云算力让一次大范围代码扫描变得可承受。第三，研究员的经验积累已经足够把问题问对。

这里可以直接拿几个数字看：Linux 内核本身有 3000 万行以上代码，crypto 子系统约 6.8 万行 C 代码，Xint Code 却能在约 1 小时内完成深度扫描。把这个速度和人工审计对比一下，就知道 AI 的角色不是“替代专家”，而是把专家的判断扩展到更大的代码空间里。

文章还提到页缓存相关漏洞经验的积累。从 Dirty COW 到 Dirty Pipe，安全社区对页缓存攻击的理解已经成熟很多。Copy Fail 正是建立在这种经验之上，只是这次它发生在内核加密路径里，而不是常见的文件系统路径。

如果再看披露节奏，也能看出这次事件的专业度。3 月 23 日报告，4 月 1 日补丁合入，4 月 29 日公开，整个协调披露周期 37 天。对发行版维护者来说，这个窗口不算宽松，但足够完成修复集成。

Copy Fail 说明了什么，也暴露了什么

Copy Fail 说明，今天真正有效的漏洞研究，不是盯着某个工具有没有“自动找洞”的能力，而是看研究员能不能提出高质量问题，再让 AI 去做高覆盖率验证。这个模式对资源有限的团队尤其重要，因为它比单纯堆算力更依赖判断力。

它也暴露了另一个现实：如果团队长期忽视底层分析、内核驱动分析和系统级归因能力，就会越来越难发现这类跨组件漏洞。只靠表层防护和用户态检测，碰到这种逻辑缺陷时会非常被动。

对安全团队来说，Copy Fail 的直接启发很明确：

• 先训练研究员提出好问题，再让 AI 放大搜索范围
• 把跨文件语义分析当成核心能力，而不是附加功能
• 继续盯住页缓存、零拷贝、权限边界这类老问题的新组合
• 把补丁验证、PoC 复现和缓解措施纳入同一套流程

我更愿意把 Copy Fail 看成一个信号：内核漏洞研究已经进入“人负责判断，AI 负责穷举”的阶段。下一批最难找的漏洞，很可能还会出现在几个单独看都没问题的设计交汇处。问题只剩一个——你的团队能不能先问对那个问题。