一次偶然的发现之旅

在过去十年中，我先后在谷歌、Waymo和OpenAI从事机器学习编译器的工作，涉及clang的CUDA支持、XLA:GPU、Triton以及OpenAI的定制硬件。自认为见多识广，但最近一周的经历却让我职业生涯中最不安：一个下午，我花费了超过一万美元，让AI代理在编译器代码中运行，发现了LLVM中数百个疑似漏洞，其中包含许多误编译问题，甚至还有一个相当严重的情况。以下是我如何走到这一步，以及未来可能的方向。

从个人项目到意外突破

2026年1月，我决定将LLVM（clang、rustc及AMD GPU编译器等的底层编译器）作为个人项目的目标，寻找其中的漏洞。我与Codex合作编写了一个模糊测试器。基本思路是：生成随机程序，将其输入编译器的部分模块运行，然后检查编译后的结果是否与原程序行为一致（通常通过直接运行两者进行比较）。经过几周努力，我发现了五个位于instcombine（LLVM的窥孔优化通道）中的漏洞并修复了它们。之后，该检测器查找新漏洞的速度明显放缓，我也逐渐失去了兴趣。

转向NVIDIA ptxas：意料之外的成果

时间来到2026年5月中旬。作为SemiAnalysis的承包商，我尝试将相同的方法应用于NVIDIA的低层编译器ptxas。起初，我预期效果不如针对LLVM的检测，原因有三：

• 模糊测试器可能“卡住”：一旦发现一个漏洞，它会不断以新方式触发相同问题。对于开源编译器如LLVM，只需修复漏洞即可继续测试；但对于闭源的ptxas，我们最多只能修改检测器以避免生成触发该漏洞的输入，实现过程极其繁琐。
• 在LLVM中，我可以仅运行单个优化通道（如instcombine），而ptxas则需要执行整个编译流程。这导致某些漏洞需要更大或更复杂的复现用例，降低了被检测器发现的概率。
• 我能够自行构建LLVM，从而通过编译选项在被测程序中添加插桩工具，帮助检测器选择“有趣”的输入，探索新代码路径。虽然AFL++提供了一些针对预编译二进制文件的插桩模式，但它们会拖慢程序运行速度，整体效果不如预期。实际上，我在检测ptxas时并未使用这些模式，仅进行了完全无导向的模糊测试。

我原以为最多只会像之前那样发现少量漏洞，然而三天内，我竟然找到了40个ptxas误编译的测试案例（一周后这个数字增至约80）。尽管其中部分案例可能对应同一底层漏洞，但这一结果仍令我大为震惊。许多复现用例化简后看起来相当“正常”，例如那些由普通指令序列组成的代码。

成果与工具

如果你好奇我（实际上是Codex和Claude）发现了哪些漏洞，它们都存储在GitHub上的FuzzX仓库中。得益于ChatGPT从5.2到5.5版本的迭代，这次编写检测器的过程出奇地轻松。我可以说是全凭“氛围编程”完成了整个工具的开发。

---

关注微信号：智享开源 ，及时了解更新信息。

原文链接：https://newsletter.semianalysis.com/p/finding-miscompiles-for-fun-not-profit