一个藏了 23 年的 Linux 漏洞,被 Claude 用几行脚本翻了出来

Nicholas Carlini 的身份很有意思——Anthropic 的研究科学家，Google Scholar 上 6.7 万次引用，做了一辈子安全研究。但他在 [un]prompted 安全大会上说了一句话，让台下一片安静：

"我这辈子从来没自己找到一个 Linux 内核的堆溢出漏洞。这东西非常、非常、非常难找。但用这些大语言模型，我找到了一堆。"

一个做了几十年安全的人，亲口说自己做不到的事，AI 做到了。不是做到一次——是批量做到。

01 一个 2003 年埋下的地雷

故事的焦点是一个 NFS 漏洞。NFS（网络文件系统）是 Linux 服务器之间共享文件的基础协议，几乎每台企业级 Linux 机器都在用。

这个漏洞藏在 NFS 的锁机制里。攻击过程不简单，但原理可以用一句话说清楚：服务器用一个 112 字节的杯子，去接一个 1056 字节的水流。

具体来说，攻击者需要两台 NFS 客户端配合操作。客户端 A 先获取一个文件锁，同时声明一个 1024 字节的 owner ID——这个长度不常见，但协议允许。接着客户端 B 来请求同一把锁，被服务器拒绝。服务器在生成拒绝响应时，要把那个 1024 字节的 owner ID 塞进响应消息里。但分配的内存缓冲区只有 112 字节。

1056 字节写进 112 字节的空间。 多出来的 944 字节直接覆写内核内存——而覆写的内容，攻击者可以通过控制 owner ID 来精确指定。

这意味着攻击者不需要登录目标机器，不需要任何特殊权限，只要能通过网络访问 NFS 服务，就能远程读甚至改写内核数据。这是一个远程可利用的堆缓冲区溢出。

这段代码是什么时候写进去的？2003 年 9 月。 那一年，Linux 2.6 内核还在测试阶段，Linus Torvalds 用的是 BitKeeper 而不是 Git（Git 2005 年才诞生）。提交记录里写着：

"I've implemented the cache as a static buffer of size 112 bytes (NFSD4_REPLAY_ISIZE) which is large enough to hold the OPEN, the largest of the sequence mutation operations."

开发者当时的判断是对的——对于 OPEN 操作来说，112 字节确实够了。但他没想到后来加入的 LOCK 操作会带上一个最大 1024 字节的 owner ID。这个逻辑断裂，在协议层是合理的，在实现层是致命的。

23 年。 经过无数次代码审查，经过无数静态分析工具的扫描，经过 fuzzing 工具的暴力测试。没人发现。因为这不是一个拼写错误或编码疏忽——你得真正理解 NFSv4 协议的握手流程，才能看到这个破绽。

而这些数字背后，藏着一个更大的信号。

02 为什么 23 年都没人找到

先说结论：不是人类太菜，是这个问题类型超出了现有工具的能力边界。

传统的漏洞发现工具有三板斧：静态分析、动态 fuzzing、人工审计。对这个 NFS 漏洞来说，三板斧全部失效。

静态分析能扫描出"缓冲区太小"这类问题，但它不理解 NFS 协议的语义。它不知道在哪个场景下 owner ID 会被填到 1024 字节，也不知道 LOCK 拒绝响应会复用 OPEN 的缓冲区。代码层面的类型完全正确，协议层面的逻辑断裂它看不到。

Fuzzing 是暴力喂随机数据看崩溃。但 NFSv4 的交互流程需要精确的三步握手，两个客户端还要按特定顺序操作。随机 fuzzing 命中这个组合序列的概率，大概等于随机按键盘写出一首唐诗。

人工审计呢？Linux 内核有超过 3000 万行代码。即使是经验丰富的安全研究员，能深入审计的范围也极其有限。NFS 协议的实现细节枯燥且复杂——大多数人扫一眼就过了。

Claude Code 不是在玩"找不同"。它理解了 NFS 协议的完整交互流程，理解了 OPEN 和 LOCK 操作之间的状态关系，理解了 owner ID 在不同上下文中的长度变化——然后把这些理解串联起来，发现了那个 112 和 1056 之间的鸿沟。

更值得注意的是 Carlini 的使用方式。他没有给 Claude 精心构造提示词，没有提供协议文档，没有做任何引导。他的脚本粗暴到令人意外——遍历 Linux 内核的每个源文件，告诉 Claude"你在一个 CTF 比赛里，找漏洞，提示：看这个文件"。就这样。一个 find 命令加一个 claude 调用，循环遍历所有文件。Claude 自己生成了完整的漏洞报告，包括那段用来解释攻击链的 ASCII 协议交互图。

这一切之所以成为可能，是因为模型能力在过去几个月里发生了质变。Carlini 测试了同一套工作流在旧模型上的表现：Opus 4.1 和 Sonnet 4.5 找到的漏洞数量，只有 Opus 4.6 的一小部分。 不是线性进步，是阶跃。

Linux 内核首席维护者 Greg Kroah-Hartman 也注意到了变化。几个月前，AI 提交的安全报告基本是垃圾——开发者管它叫"AI slop"。然后大约一个月前，情况变了。他的原话："Something happened a month ago, and the world switched. Now we have real reports."

那对普通人意味着什么？

03 安全行业的游戏规则变了

Carlini 在演讲中提到一个尴尬的瓶颈：他手里有几百个未验证的内核崩溃报告，但没时间一一确认。 他不想给内核维护者发垃圾，所以只能自己先筛。AI 找漏洞的速度，已经超过了人类审核的速度。

瓶颈不再是"找不到"，而是"验证不过来"。 安全行业的历史上，这是第一次。

这还不是 Claude 一家的故事。OpenAI 的 o3 模型分析了超过 1.2 万行代码，发现了 Linux 内核 SMB 实现中的一个 use-after-free 漏洞——传统静态分析始终漏掉的竞态条件。安全初创公司 AISLE 发现了 OpenSSL 2026 年 1 月安全补丁中全部 12 个零日漏洞，其中一个高危栈缓冲区溢出不需要有效密钥就能触发。

Firefox——可能是地球上被审计得最彻底的浏览器——在两周内被 Opus 4.6 找出了 22 个漏洞。 一个漏洞从开始扫描到被发现，只用了 20 分钟。

这意味着什么？

对开发者来说，如果你维护的开源项目有任何攻击面，现在就可以用 Claude Code 做一轮扫描。不是"未来建议"，是"今天就能做"。Anthropic 已经推出 Claude Code Security 研究预览版，开源维护者可以申请加急访问。

对安全团队来说，防御窗口正在急剧缩短。以前从漏洞引入到被发现，可能是十年。现在可能是几周，甚至几天。攻守双方都在拿到同一把武器。 Carlini 自己也承认：如果发现漏洞和利用漏洞之间的差距继续缩小，风险计算将发生根本改变。

对普通人来说，好消息是你的操作系统会更安全——因为 AI 能在攻击者之前找到并修复更多漏洞。坏消息是，如果攻击者也在用同样的工具，那些尚未修复的漏洞被发现和利用的速度也会大幅加快。

安全领域正在经历自己的 AlphaGo 时刻。 2016 年，围棋界一夜之间发现 AI 已经超越人类顶尖棋手。2026 年，安全研究员们面对的是一个能在几小时内翻遍 3000 万行代码、理解复杂协议交互、批量输出漏洞报告的系统。

Carlini 在演讲结尾没有留任何余地：

"I expect to see an enormous wave of security bugs uncovered in the coming months."

浪潮已经在拍岸了。