历史首次！o3 找到 Linux 内核零日漏洞，12000 行代码看 100 遍揪出，无需调用任何工具

AI 成功找到 Linux 安全漏洞，还是内核级别的零日漏洞。

刚刚，OpenAI 总裁转发了独立研究员 Seen Heelan 的实验成果：用 o3 模型找到了 Linux 内核 SMB 实现中的一个远程零日漏洞。

更让人惊讶的是，整个过程中没有用到任何复杂的工具——没有脚手架、没有智能体框架、没有工具调用，仅仅是 o3 API 本身。

这个漏洞被编号为 CVE-2025-37899，是 SMB" 注销 " 命令处理程序中的一个释放后使用（use-after-free）漏洞。

据作者透露，这是首次公开讨论的由大模型发现的此类漏洞。

有网友看过发现过程后感叹，原以为会有很疯狂的实验设置，但其实只是把一堆代码缝到一起，让 o3 检查 100 次。

希望其他白帽黑客已经开始像这样检查其他关键操作系统了。

OpenAI 首席研究官 Mark Chen 表示：像 o3 这样的推理模型正开始助力深度技术工作和有意义的科学发现。接下来一年，类似这样的成果将会越来越普遍：

Sean Heelan 是一位独立研究员，专注于基于大模型的漏洞研究和漏洞利用自动化生成。

他原本在手动检查 Linux 内核的 KSMBD（内核态 SMB3 协议实现）漏洞，想要暂时远离大模型相关的工具开发。

但 o3 发布后，他忍不住想测试一下：" 既然我手里已经有这些漏洞，不如看看 o3 能不能找到它们？"

他先用一个自己手动发现的漏洞 CVE-2025-37778 作为测试。这是 Kerberos 认证路径中的一个释放后使用漏洞，是测试大模型能力很好的基准，因为：

它是 Linux 内核远程攻击面的一部分

它并不简单，发现他需要理解如何触发特定的会话状态、认证函数的多条执行路径、跨函数的对象生命周期管理

但它也并非极其复杂，作者本人可以在 10 分钟内带着同时了解涉及到的约 3300 行代码

接下来开始实验之前，还需要搞清楚一个问题，该给大模型展示哪些代码？

理想情况当然是大模型读取整个代码库并输出结果，但实践中上由于上下文窗口的限制还无法事先。

最终 Heelan 为 LLM 提供了 " 会话设置 " 命令处理程序的代码，包括它调用的所有函数的代码等等，直到调用深度达到 3（这是包含推理漏洞所需代码所需的深度），还包含了命令处理器、连接建立 / 拆除、请求分发等完整上下文。

提示词中告诉 o3 专门寻找 use-after-free 漏洞，提供 KSMBD 架构说明，强调要避免误报，每个实验运行 100 次，统计成功率。

相关代码和提示词已开源在 GitHub 上。

Heelan 还按同样流程测试了 Claude3.7 和 Claude 3.5 作为对比，结果 o3 的表现让人眼前一亮：

OpenAI o3: 100 次运行中成功找到 8 次漏洞

Claude 3.7: 100 次中找到 3 次

Claude 3.5: 100 次中一次都没找到

此外有意思的的是，o3 和 Claude 的输出风格完全不同。

o3 生成的像人类写的漏洞报告，结构清晰、重点突出

Claude 更像思维流或工作日志，细节丰富但略显冗长。

接下来发生的事情更精彩了。

Heelan 想测试 o3 在更大代码量下的表现，于是给它提供了所有 SMB 命令处理程序的代码，约12000 行代码。

虽然找到原始漏洞的成功率降到了 1%，性能明显下降。但在运行结果中，o3 报告了一个全新的漏洞。

Heelan 自己之前也不知道这个漏洞，它同样是由于 sess->user 的释放造成的，但这次是在会话注销处理程序中。

o3 自己对这个漏洞的解释如下。

当一个 ksmbd 工作线程还在执行使用 sess->user 的请求时，另一个处理同一会话 SMB2 LOGOFF 的线程释放了该结构。没有同步机制保护该指针，所以第一个线程会解引用已释放的内存——这是一个经典的释放后使用漏洞，会导致内核内存损坏和任意代码执行。

更有意思的是，研究员发现 o3 不仅能找到漏洞，某些情况下修复方案比人类更完善。

对于之前的 Kerberos 认证漏洞，Heelan 最初提出的修复是简单地将指针置空：

if ( sess->state == SMB2_SESSION_VALID ) { ksmbd_free_user ( sess->user ) ; sess->user = NULL; // 添加这行 }

但 o3 的报告中有指出这个修复不够充分，因为 SMB 协议允许两个不同的连接 " 绑定 " 到同一个会话，在释放和置空之间的短暂窗口期，另一个线程仍可能访问这个指针。

最终 Heelan 承认，如果使用 o3 来找和修复原始漏洞，" 理论上 " 会比自己完成更好。

之所以加上 " 理论上 " 的限定，是因为现在 AI 误报的比例有点高，人类很难认真仔细地查看 o3 的每份报告。

不过他也认为随着技术的发展，这个比例只会越来越低。

Heelan 在报告结尾感慨道：

大模型在程序分析技术的能力空间中，处于一个比我们见过的任何东西都更接近人类的位置。考虑到创造力、灵活性和通用性，LLM 更像是人类代码审计员，而不是符号执行、抽象解释或模糊测试。

他特别强调，如果你从事安全研究工作，现在应该开始密切关注了：

专家级研究员不会被取代，反而会变得更高效

对于 10000 行以内的代码问题，o3 有相当大的概率能解决或帮助解决

虽然仍有约 1:50 的信噪比问题，但这已经值得投入时间和精力

不过也有人看到了其中的风险：

如果坏人利用 AI 的能力找到类似的漏洞并攻击系统又如何呢？

— 完 —

量子位 AI 主题策划正在征集中！欢迎参与专题365 行 AI 落地方案，一千零一个 AI 应用，或与我们分享你在寻找的 AI 产品，或发现的AI 新动向。

也欢迎你加入量子位每日 AI 交流群，一起来畅聊 AI 吧～

一键关注 点亮星标

科技前沿进展每日见

一键三连「点赞」「转发」「小心心」

欢迎在评论区留下你的想法！