AI 在跑，内核在哭
Claude 发现 Linux 中藏了 23 年的漏洞
一个潜伏了 23 年的 Linux 内核漏洞，被 AI 用一句简单的提示词挖了出来。内核维护者说"整个世界都不一样了"。这事意味着什么？
2003 年，一位 Linux 内核开发者提交了一段 NFS（网络文件系统）驱动代码，涉及 DRC（Duplicate Request Cache）机制中的会话管理逻辑 [1]。没有人注意到，这段代码里藏了一个堆缓冲区溢出的隐患。
23 年后，Anthropic 的研究科学家 Nicholas Carlini 使用 Claude Code，在一场没有预设目标的"漫游式漏洞扫描"中，把这个漏洞从堆积如山的内核代码里翻了出来。
据 InfoQ 等多家科技媒体报道 [2]，Carlini 在 [un]prompted AI 安全大会上披露了这一发现。他使用 Claude Code 在 Linux 内核中识别出 5 个可远程利用的真实漏洞，其中包括这个自 2003 年起就存在的 NFS 漏洞。目前已全部确认并修复，另有数百个潜在崩溃点仍在等待人工验证。
漏洞覆盖面极广——覆盖了 NFS、io_uring、futex 和 ksmbd 等多个内核子系统，并非集中在某一个容易被"盯上"的模块。
Carlini 发现漏洞的方式，比大多数人想象中要简单得多。
他写了一个 bash 脚本 [3]：遍历 Linux 内核源码树中的每一个 .c 文件，对每个文件，告诉 Claude Code —— "你在参加一场 CTF 比赛，去找漏洞。"
# 遍历内核源码中的所有文件
find . -type f -print0 | while IFS= read -r -d '' file; do
claude \
--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没有自定义工具。没有复杂的提示词工程。没有经过微调的专用模型。就是一个循环，加上一句简单的指令。
而这个 NFS 漏洞的利用原理，本身就值得细看——它并不简单。博客作者 Michael Lynch 在详细拆解中还原了漏洞的逻辑 [4]：
攻击方式需要两个协同的 NFS 客户端针对一台 Linux NFS 服务器发起操作。客户端 A 先申请一个 owner ID 长度为 1024 字节的文件锁——这个长度虽然异常，但合法。随后，客户端 B 尝试获取同一把锁并被拒绝，服务器会生成包含 owner ID 的拒绝响应。问题在于服务器响应缓冲区只有 112 字节，而拒绝消息总长为 1056 字节。结果内核原封不动地把 1056 字节写入 112 字节缓冲区，使攻击者能够完全控制被覆盖的内核内存。
这个漏洞需要理解复杂的 NFS 协议交互细节——跨多个客户端和服务器进行推理。它恰恰是人类审计者最容易遗漏的那种跨模块漏洞。
如果说 Carlini 的发现是个例，那么来自内核维护团队的反应就是整个安全生态的风向标。
Greg Kroah-Hartman，Linux 内核的资深维护者（stable 分支维护人），在 Reddit 讨论帖中描述了他的切身感受 [5]：
"大约一个月前发生了某些变化，整个世界都不一样了。现在我们收到的是真实报告……所有开源安全团队现在都在面对这个情况。"
另一位移居内核维护者 Willy Tarreau 在 LWN.net 上提供了更具体的数据 [6]：内核安全邮件列表的报告量已从 每周 2-3 条上升到每天 5-10 条，而且大多数是有效的。这意味着 AI 发现漏洞的效率已经不是一个数量级的提升，而是两个数量级。
去年 2-3 条/周 大部分是噪音 | → | 现在 5-10 条/天 大部分有效 |
这个转变发生在短短几个月内。Carlini 自己的实验也证实了这一点 [4]：8 个月前发布的 Opus 4.1 在同样的任务上几乎无效，6 个月前发布的 Sonnet 4.5 只能发现一小部分，而当前的 Opus 4.6 找到了 5 个真实漏洞和数百个可疑点。
能力的跃迁是指数级的。这并不是模型突然"学会"了挖漏洞，而是随着代码理解、长上下文推理和多步推理能力的提升，之前"够不着"的任务进入了可做区间。
长期从事漏洞研究的资深安全研究员 Thomas Ptacek（曾以发现 SSL/TLS 协议漏洞闻名）在 Hacker News 的讨论中给出了一个精准的技术判断 [7]：基于 LLM 的漏洞发现代表了本质完全不同的工具——它是模糊测试和静态分析两者的超集。
他解释了两者的局限：静态分析器会产生大量假设性漏洞，人工确认成本极高；模糊测试能找到漏洞但缺乏上下文，产生的崩溃往往数月难以定性。LLM Agent 则能递归生成假设、执行验证步骤、给出置信度，通过明确的攻击路径把发现放回上下文 [7]。
另一个值得关注的进展来自 Redis 创始人 Salvatore Sanfilippo（antirez）。他在同一条讨论中指出，AI 正在自我验证——误报往往在进入人工审查前就被第二条流水线自动过滤了 [7]。
误报率方面，博客作者 Michael Lynch 根据实测给出的数字是 低于 20% [4]——即每 5 条 AI 漏洞报告中有至少 4 条是真实问题。
影响不止一面。在 Reddit 和 Hacker News 的讨论中，"双重用途"（dual-use）风险被反复提及 [5][7]：
"如果 AI 能挖出 Linux 中潜伏 23 年、人工审计遗漏的漏洞，那么具备同等能力的对手也能把这套流程规模化用于针对性目标攻击。"
蓝队（防御方）看到了前所未有的压力——每天 5-10 条真实漏洞报告涌入，而人工验证永远是瓶颈。红队（攻击方）看到了前所未有的机会——大规模、自动化、不知疲倦的漏洞挖掘正在成为现实。
Linux 内核安全邮件列表的报告量陡升本身就是一个信号：以前的噪音太多，维护者会选择性忽略；现在大多数报告是真实的，维护者的工作负担反而变得更重了。
传统上，"有多少双眼睛，就有多浅显的 Bug"（Linus 定律）是开源安全的基本信念。但内核中大量代码年久失修——一句 2003 年的提交，甚至早于 git 本身诞生 [4]。 作者已离开，维护者在疲于奔命，审查流于形式。
1. 零疲劳：不会跳过"无聊"的代码段
2. 全覆盖：可遍历整个代码库，不留死角
3. 指数增长：能力提升速度远超人力
对所有依赖开源组件的企业而言，这意味着：那些"看了很多年也没出事"的依赖，在 AI 审计面前可能不再是安全的。当攻击者已经用上 AI 自动审计，而防御者还在依赖人工代码审查，这个差距将快速扩大。
[1] Linux 内核 2003 年 NFS DRC 漏洞提交记录
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a334f8d5f34e
[2] InfoQ 中文报道：Claude Code发现了Linux内核中隐藏23年的可远程利用漏洞
www.infoq.cn/article/5RYdZtLgisqRJ65zJBpo
[3] Michael Lynch 详细拆解文章
mttaylorr.dev/posts/claude-nfs-vulnerability/
[4] [un]prompted AI 安全大会演讲（YouTube）
youtube.com/watch?v=1cQp71pBMkM
[5] Greg Kroah-Hartman Reddit 讨论
reddit.com/r/linux/comments/1l7wmqy/claude_finds_remote_exploit_in_linux_kernel/
[6] LWN.net AI 安全审计相关报道
lwn.net/Articles/1004096/
[7] Thomas Ptacek & antirez Hacker News 讨论
news.ycombinator.com/item?id=44107476
[8] Anthropic 官方博文：Claude Code for vulnerability discovery
anthropic.com/news/claude-code-vulnerability-discovery
— 关注「彼岸前哨」 —
站在人类与 AI 的交叉口
看见变化，理解变化
10个月宝宝每天需要喝多少奶粉？
