sess->user。代码的假设是，后续要么会重新初始化sess->user，要么在返回错误后不再使用它。但事实并非如此，攻击者可以构造特定路径，使得sess->user不被重新初始化，并且在返回错误后仍被访问，导致UAF。LLM测试设置：
1. 代码范围：Sean提取了“会话设置”命令处理函数及其调用的三层深度内的所有函数代码，再加上数据读取、请求解析、连接拆除等相关代码，总计约3.3k行C代码（约2.7万tokens） 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并非完美无瑕，它仍可能产生无意义的结果，令人沮丧。但不同的是，它给出正确结果的几率已经高到值得你投入时间和精力在真实问题上尝试它。