大神都惊了！OpenAI o3模型单挑Linux内核，竟揪出一个0-day高危漏洞

零日漏洞或零时差漏洞（英语：zero-day vulnerability、0-day vulnerability）是指软件或硬件中还没有有效补丁的安全漏洞，并且其供应商通常不知晓，而零日攻击或零时差攻击（英语：zero-day exploit、zero-day attack）则是指利用这种漏洞进行的攻击。“零日”一词原指已发布零天（未公开发布）的盗版软件，后来代指修复漏洞的时间期限。由于漏洞已经被描述或被利用，留给软/硬件供应商来准备补丁的时间只有“零天”

o3模型在Linux内核的SMB实现中挖出了一个远程0-day漏洞（CVE-2025-37899）！全程只用了API，没搭任何复杂框架或Agentic框架，在基准测试中，o3表现优于Claude Sonnet 3.7达2-3倍

这两天安全研究员Sean Heelan分享了一段令人瞠目结舌的经历。他一直在审计Linux内核中的ksmbd模块（一个在内核空间实现SMB3协议的文件共享服务），本来是想从LLM工具开发中歇口气，OpenAI的o3模型发布后，他忍不住用自己之前在ksmbd中发现的漏洞来“考考”o3。

没想到，这一考，就考出了个大新闻！

一、基准测试：o3小试牛刀

Sean首先用一个他手动发现的漏洞CVE-2025-37778（姑且称之为“Kerberos认证漏洞”）来测试o3。这是一个在处理Kerberos认证路径中的“会话设置”请求时发生的UAF漏洞。

漏洞原理简述： krb5_authenticate函数在检测到会话状态为SMB2_SESSION_VALID时会释放sess->user。代码的假设是，后续要么会重新初始化sess->user，要么在返回错误后不再使用它。但事实并非如此，攻击者可以构造特定路径，使得sess->user不被重新初始化，并且在返回错误后仍被访问，导致UAF。

LLM测试设置：

1. 1. 代码范围：Sean提取了“会话设置”命令处理函数及其调用的三层深度内的所有函数代码，再加上数据读取、请求解析、连接拆除等相关代码，总计约3.3k行C代码（约2.7万tokens）
2. 2. Prompt核心：
   * 明确指示LLM寻找UAF漏洞。
   * 提供ksmbd的高级概述、架构和威胁模型。
   * 强烈引导LLM避免误报，宁可漏报也不要错报（虽然Sean也承认这更像一种“祈祷”）。

测试结果 (100次运行)：

o3模型：8次成功找出该漏洞，66次判断无漏洞（漏报），28次误报。真实漏洞与误报比例约为1:4.5。这意味着，在这个特定实验中，最多看5个误报就能找到一个真漏洞

Claude Sonnet 3.7：100次运行中仅找到3次

Claude Sonnet 3.5：100次运行中0次找到

Sean特意强调，这个1:4.5的比例并不代表o3在整个ksmbd代码库上的表现。但关键在于，对于给定的3.3k行真实、非平凡的C代码，o3能以合理的信噪比和2-3倍于竞品的效率识别出这个UAF漏洞，这本身就是LLM能力的一大步

o3的报告风格更像人类写的漏洞报告，凝练且聚焦；而Sonnet 3.7则更像工作日志或思考流。各有优劣，但o3的输出通常因其结构和重点更易于理解

二、意外：o3独立发现0-day漏洞 (CVE-2025-37899)！

在确认o3能找到已知漏洞后，Sean加大了难度：他把ksmbd中所有命令处理相关的代码（主要在smb2pdu.c，约9k LoC），再加上连接设置、拆除、命令分发等代码，总计约12k LoC（约10万输入tokens）喂给了o3，同样运行100次。

结果呢？

对于之前的“Kerberos认证漏洞”，o3在更大的代码量下只成功找到了1次，性能有所下降。

但惊人的是，o3在其他运行的输出中，报告了一个全新的、类似的UAF漏洞！这次问题出在SMB的“logoff”（注销）命令处理中。这就是后来的CVE-2025-37899！

这个新漏洞同样是由于sess->user被释放后仍被其他线程访问导致。o3对漏洞描述：

Sean表示，读到这份报告时，他对AI工具在漏洞研究中的潜力有了新的认知。即使AI止步于此，安全研究员也应该开始思考如何将其整合进工作流。当然，1:50左右的信噪比（针对这个0-day的发现）处理起来仍有挑战，但这已是实实在在的进展。

三、o3的洞察力：甚至超越人类专家？

更有意思的一点是，当Sean最初修复那个“Kerberos认证漏洞”时，他的补丁是这样的：

-       if (sess->state == SMB2_SESSION_VALID)
-           ksmbd_free_user(sess->user);
+       if (sess->state == SMB2_SESSION_VALID) {
+           ksmbd_free_user(sess->user);
+           sess->user = NULL;
+       }

他仅仅是在释放后将sess->user置为NULL

但在阅读了o3关于logoff漏洞（CVE-2025-37899）的报告后，Sean意识到他最初的这个修复是不够的。因为SMB协议允许不同连接“绑定”到同一会话。在logoff场景下，即使sess->user被设为NULL，如果另一个线程在ksmbd_free_user之后、sess->user = NULL之前这极短的窗口期内访问sess->user，依然会出问题。Sean之前在ksmbd中利用过这个特性攻击其他漏洞，但在修复Kerberos漏洞时却忽略了这一点

回过头再看o3针对Kerberos认证漏洞的某些报告，Sean发现o3有时也犯了和他一样的错误，但在其他一些报告中，o3正确地指出了仅将sess->user设为NULL不足以修复问题，因为它考虑到了会话绑定的可能性

这意味着，如果Sean当初用o3来辅助发现和修复Kerberos漏洞，理论上他能做得比自己单独做更好！当然，他也坦言，以目前o3的误报率，要仔细甄别每一份报告并发现那个“正确”的解决方案，挑战依然巨大。但这个趋势是积极的

写在最后

Sean Heelan的经历证明，LLM在程序分析能力上已经达到了一个前所未有的、更接近人类的水平。相比符号执行、抽象解释或Fuzzing等传统技术，LLM在创造力、灵活性和通用性方面，更像一个人类代码审计员

自GPT-4以来，LLM在漏洞研究中的潜力已初现端倪，但真实世界问题的结果往往未达预期。o3的出现改变了这一点。我们现在拥有一个在代码推理、问答、编程和问题解决方面表现足够出色的模型，它能够真正提升人类在漏洞研究中的表现

o3并非完美无瑕，它仍可能产生无意义的结果，令人沮丧。但不同的是，它给出正确结果的几率已经高到值得你投入时间和精力在真实问题上尝试它。

参考：

https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/