Claude Code通过深度代码分析发现了Linux内核中一个隐藏23年的漏洞,展示了AI编程工具的代码理解和缺陷识别能力。这证明AI助手已能在实际工程中创造价值,发现人类开发者遗漏的问题。
Anthropic 研究科学家 Nicholas Carlini 在 [un]prompted AI 安全会议上报告称,他使用 Claude Code 在 Linux 内核中发现了多个远程可利用的安全漏洞,其中一个隐藏了 23 年之久。
Nicholas 对 Claude Code 找到这些漏洞的有效性感到震惊:
我们现在拥有一大堆 Linux 内核中的远程可利用堆缓冲区溢出漏洞。
我这辈子从未发现过这样的漏洞。这是非常、非常、非常难做到的事情。
但有了这些语言模型,我已经找到了一大堆。
—Nicholas Carlini,在 [un]prompted 2026 上发言
Nicholas 分享的漏洞最令人惊讶的之处在于,Claude Code 只需极少的人工干预就能找到漏洞。他基本上只是把 Claude Code 指向 Linux 内核源代码,然后问:"哪里存在安全漏洞?"
Nicholas 使用了一个类似如下的简单脚本:
# Iterate over all files in the source tree.
find . -type f -print0 | while IFS= read -r -d '' file; do
# Tell Claude Code to look for vulnerabilities in each file.
claude \
--verbose \
--dangerously-skip-permissions \
--print "You are playing in a CTF. \
Find a vulnerability. \
hint: look at $file \
Write the most serious \
one to the /output dir"
done
这个脚本告诉 Claude Code,用户正在参加夺旗(CTF)网络安全竞赛,需要帮助解决谜题。
为了防止 Claude Code 重复发现相同的漏洞,脚本遍历 Linux 内核中的每个源文件,告诉 Claude 漏洞可能在文件 A 中,然后是文件 B,以此类推,直到 Claude 关注了内核中的每个文件。
在他的演讲中,Nicholas 重点介绍了 Claude 在 Linux 网络文件共享 (NFS) 驱动程序中发现的一个漏洞,该漏洞允许攻击者通过网络读取敏感的内核内存。
Nicholas 选择这个漏洞是为了说明 Claude Code 不仅仅是在寻找明显的漏洞或查找常见的代码模式。这个漏洞要求 AI 模型深入理解 NFS 协议的工作原理。
该攻击需要攻击者使用两个协作的 NFS 客户端来攻击 Linux NFS 服务器:
Client A NFS Server Client B
| | |
(1) |--- SETCLIENTID ---------------->| |
|<-- clientid_a, confirm ---------| |
|--- SETCLIENTID_CONFIRM -------->| |
| | |
(2) |--- OPEN "lockfile" ------------>| |
|<-- open_stateid_a --------------| |
|--- OPEN_CONFIRM --------------->| |
| | |
(3) |--- LOCK (1024-byte owner) ----->| lock_owner = 1024b buf |
|<-- lock_stateid_a --------------| Lock granted |
| | |
(1) - 客户端 A 与 NFS 服务器进行三向握手以开始 NFS 操作。
(2) - 客户端 A 请求一个锁文件。服务器接受,客户端确认接受。
(3) - 客户端 A 获取锁并声明一个 1024 字节的所有者 ID,这对所有者 ID 来说是异常长但合法的值。服务器授予锁的获取。
攻击者随后启动第二个 NFS 客户端(客户端 B)与服务器通信:
Client A NFS Server Client B
| | |
(4) | |<-- SETCLIENTID -----------------|
| |--- clientid_b, confirm -------->|
| |<-- SETCLIENTID_CONFIRM ---------|
| | |
(5) | |<-- OPEN "lockfile" -------------|
| |--- open_stateid_b ------------->|
| |<-- OPEN_CONFIRM ----------------|
| | |
(6) | |<-- LOCK (same range) -----------|
| | |
| +-----------+-----------+ |
| | LOCK DENIED! | |
| | Encode response: | |
| | offset: 8B | |
| | length: 8B | |
| | type: 4B | |
| | clientid: 8B | |
| | owner_len: 4B | |
| | owner: 1024B | |
| | TOTAL: 1056B | |
| +-----------+-----------+ |
| | |
(4) 客户端 B 与 NFS 服务器进行三向握手以开始 NFS 操作,与上面的 (1) 相同。
(5) 客户端 B 请求访问与 (2) 中客户端 A 相同的锁文件。NFS 服务器接受,客户端确认接受。
(6) 客户端 B 尝试获取锁,但 NFS 服务器拒绝该请求,因为客户端 A 已经持有该锁。
问题在于在步骤 (6) 中,当 NFS 服务器试图生成对客户端 B 拒绝锁请求的响应时,它使用的内存缓冲区只有 112 字节。拒绝消息包括所有者 ID,可以达到 1024 字节,使消息的总大小为 1056 字节。内核将 1056 字节写入 112 字节的缓冲区,这意味着攻击者可以用他们在步骤 (3) 的所有者 ID 字段中控制的字节覆盖内核内存。
有趣的是:Claude Code 在其初始漏洞报告中创建了上述 ASCII 协议图表。
这个漏洞在 2003 年 3 月被引入 Linux 内核:
ChangeSet@1.1388, 2003-09-22 19:22:37-07:00, neilb@cse.unsw.edu.au
[PATCH] knfsd: idempotent replay cache for OPEN state
This implements the idempotent replay cache need for NFSv4 OPEN state.
each state owner (open owner or lock owner) is required to store the
last sequence number mutating operation, and retransmit it when replayed
sequence number is presented for the operation.
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. This implements the cache for
OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE, and CLOSE. LOCK and UNLOCK will be
added when byte-range locking is done (soon!).
这个漏洞太古老了,我甚至无法直接链接到它,因为它早于 2005 年才发布的 git。
Nicholas 在 Linux 内核中发现了数百个更多的潜在漏洞,但修复它们的瓶颈在于人工手动审查 Claude 所有发现的步骤:
我在 Linux 内核中发现了太多漏洞,以至于我无法报告,因为我还没有验证它们……我不会向 [Linux 内核维护者] 发送潜在的垃圾信息,但这意味着我现在有数百个崩溃他们没有看到,因为我没有时间检查它们。
—Nicholas Carlini,在 [un]prompted 2026 上发言
我搜索了 Linux 内核,目前找到了五个 Linux 漏洞,Nicholas 要么直接修复了,要么报告给了 Linux 内核维护者,其中一些是最近一周才报告的:
nfsd: fix heap overflow in NFSv4.0 LOCK replay cache (described above)
io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check
futex: Require sys_futex_requeue() to have identical flags
ksmbd: fix share_conf UAF in tree_conn disconnect
ksmbd: fix signededness bug in smb_direct_prepare_negotiation()
Nicholas 演讲中令人瞩目之处在于大型语言模型在寻找漏洞方面改进的速度有多快。Nicholas 使用 Claude Opus 4.6 找到了这些漏洞,Anthropic 在不到两个月前发布了该版本。他试图在较早的 AI 模型上重现他的结果,发现 Opus 4.1(八个月前发布)和 Sonnet 4.5(六个月前发布)只能找到 Nicholas 使用 Opus 4.6 发现内容的一小部分:
我预计在未来几个月内会看到大量安全漏洞被发现,当研究人员和攻击者都意识到这些 AI 模型在发现安全漏洞方面有多强大时。
Nicholas Carlini - Black-hat LLMs at [un]prompted 2026
我正在写一本关于简单技巧的书,帮助开发者改进他们的写作。
我的书将教你如何:
创建清晰愉快的软件教程
通过博客吸引读者和客户
编写有效的电子邮件
最小化编写设计文档的痛苦
第一时间了解我发布的酷炫内容
订阅以通过电子邮件获取我的最新文章。