在本文中，我将分享我是如何利用 OpenAI 最新的 o3 大模型发现一个 Linux 内核中的远程 0day 漏洞（CVE-2025-37899）的。更令人兴奋的是，我只使用了 o3 的 API，无需任何复杂的脚本框架、代理架构或辅助工具。
我最近在审计 Linux 内核的 SMB 模块（ksmbd）时发现了这个漏洞。ksmbd 是一个在内核空间实现 SMB3 协议的服务端组件，用于网络文件共享。本来这个项目是想暂时远离 LLM 相关的开发工作，但 o3 的发布让我决定用 ksmbd 中已有的一些漏洞来测试它的能力。结果令人惊喜：它竟然找出了一个我之前没发现的 0day 漏洞。
这个漏洞编号为 CVE-2025-37899，出现在 SMB 的 logoff 命令处理逻辑中，是一个典型的 use-after-free（UAF）问题。理解这个漏洞需要分析并发连接的行为，o3 成功地识别出了一个对象在未被引用计数保护的情况下被释放，但仍可能被其他线程访问的风险。这或许是首次公开有 LLM 模型独立发现这类漏洞的案例。
要点总结
文章核心观点：
o3 模型在代码理解和漏洞分析能力上迈出了重要一步。
如果你从事漏洞研究工作，现在是时候认真考虑将 LLM 融入到你的分析流程中了。虽然 o3 还远不能替代顶级的漏洞研究专家，但它已经足以提升你的效率，尤其当你面对的是小于一万行代码的问题时。
用 CVE-2025-37778 评估 o3 的能力
在 o3 发现 0day 之前，我先用我手动发现的另一个漏洞（CVE-2025-37778）来测试它。这是一个与 Kerberos 身份验证相关的 use-after-free 漏洞。我们暂且称它为 “Kerberos 身份验证漏洞”。
其根源如下所示（简化版 C 代码）：
if (sess->state == SMB2_SESSION_VALID)
ksmbd_free_user(sess->user);
retval = ksmbd_krb5_authenticate(...);
if (retval)
return -EINVAL;
问题在于，如果满足条件 sess->state == SMB2_SESSION_VALID，那么系统会释放 sess->user，但这之后仍有可能继续访问该变量，导致 UAF。这个漏洞不算特别复杂，但它涵盖了多个关键点，例如：
- 如何制造出
sess->state == SMB2_SESSION_VALID的状态。 - 理解
ksmbd_krb5_authenticate()有哪些路径不会重新初始化sess->user。 - 分析释放后的
sess->user是否还会在其他地方被访问。
我估算了一下，从请求包进入到触发漏洞的代码路径，大约涉及 3300 行代码。这使得它成为测试 LLM 代码分析能力的理想案例。
如何喂代码给 LLM 模型？
我采用的是“逐层展开”的方式：
- 提供
session setup命令处理函数及其调用的所有函数（最多展开到调用深度为 3）。 - 包括处理请求的相关代码，如读取数据、命令分发、连接释放等。
- 总共约 3.3k 行代码（约 27k tokens）。
为了测试，我运行了 100 次，让 o3 识别 use-after-free 漏洞：
- o3 成功识别 8 次；
- 66 次未识别出漏洞（漏报）；
- 其余 26 次是误报。
相比之下，Claude Sonnet 3.7 模型在 100 次中识别了 3 次，Claude 3.5 完全未识别。
这意味着 o3 在处理真实漏洞时表现出更高的准确性，尽管误报率仍较高（TP:FP 约为 1:4.5），但已经具备实用性。
o3 意外发现 0day 漏洞（CVE-2025-37899）
之后我把所有的 SMB 命令处理函数（约 9k 行）以及连接处理代码一起喂给 o3，总共约 12k 行代码（~10 万 tokens），再次运行 100 次。
尽管性能有所下降，o3 只在 1 次中识别出了 “Kerberos 漏洞”，但令人惊讶的是，它还发现了一个我从未注意过的新漏洞 —— CVE-2025-37899。
这个漏洞也涉及对 sess->user 的释放，但出现在 logoff 命令处理流程中。问题出在多个连接可绑定到同一个会话，且在处理 logoff 命令时释放 sess->user，但没有等待其他连接上的线程结束使用该结构，造成并发访问已经释放的内存。
简要分析：
- 一个连接执行普通请求（如
WRITE），另一连接发起LOGOFF。 - 第二个线程释放了
sess->user，但第一个线程可能仍在使用。 - 由于没有加锁保护，会触发经典的 UAF 问题，严重时可能导致任意内核代码执行。
o3 不仅识别出了这个问题，还在报告中准确描述了数据流与时间窗口的关系，这令人印象深刻。
修复误区和 AI 的启发
在修复 Kerberos 漏洞时，我原本以为给 sess->user = NULL 就足够，但 o3 指出这仍无法避免 UAF。在 SMB 的会话绑定机制下，多个线程可同时访问同一个会话，必须确保同步机制到位，否则仍存在竞争访问的风险。
这让我意识到：使用 o3 不仅可以帮助发现漏洞，还能帮我们更全面地思考漏洞根因与修复策略。
总结
o3 展示了 LLM 在程序漏洞分析领域的巨大潜力。与传统的符号执行、模糊测试等方法相比，o3 更接近于一个高效的“人类审计员”：
- 能理解上下文；
- 能做逻辑推理；
- 甚至能发现之前未暴露的问题。
虽然它还不完美，误报率仍高，但它已经具备实用价值。如果你是从事安全审计、漏洞挖掘的专业人士，建议你尽早尝试将 o3 纳入工作流程 —— 或许会带来意想不到的收获。
