加载失败
这篇讨论围绕 Nicholas Carlini 在 unpromptedcon 上展示的案例：他用 Claude Code（Anthropic 的 AI 编程代理）和 Claude Opus 4.6（Anthropic 的编码模型）去审 Linux kernel（Linux 操作系统内核）代码，找到一个长期未被注意到的越界漏洞。评论里补充了漏洞细节：某个协议字段 owner ID 允许到 1024 字节，但消息缓冲区只有 112 字节，导致内核把 1056 字节写进 112 字节缓冲区。很多人把这件事放到更大的 AI security research 语境里理解：先用模型找候选漏洞，再用另一轮模型或人工去验证、生成 PoC 和测试用例。争议集中在这到底是 Claude 的突破，还是 static analysis（静态分析）、fuzzing（模糊测试）和长期人工审查不足终于被更便宜的自动化放大了。
不少评论把这次发现看成 Claude Code（Anthropic 的 AI 编程代理）在代码审查和漏洞挖掘上的实战样本，而不是纯演示。有人表示，把新代码批量丢给模型，再问哪里有 bug，是开发者接入 AI 的最佳切入点，尤其适合 threading 和 distributed system 这类人工排查很慢的场景。也有人分享了多轮流程：先让模型找可疑点，再让另一轮模型做 verification，甚至自动写 PoC 或测试用例。评论里还举了 deadlock、compiler bug 之类例子，说明它在某些具体任务上已经能省下很多人工时间。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
另一派的重点是误报和验证成本，而不是模型会不会看见问题。有人指出，这个漏洞更像是长期没人检查，而不是隐藏了 23 年；长字段塞进固定缓冲区这种问题本来就很像 static analysis 的典型目标。争论集中在：模型能否把候选项缩到足够小，并用 ASAN、PoC 或可复现步骤证明它真的可触发。支持者则反驳，真正困难的是找到高质量 candidate，而不是把一个已经定位到的 candidate 再跑一遍。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12]
很多人对标题和宣传口径保持怀疑，担心这是把一次成功包装成 Claude 比实际更聪明。有人说自己在真实项目里看到的更多是 hallucination、奇怪的不一致，以及本来过不了人类 code review 的代码。也有人承认它在某些场景里已经非常好用，但更像强力工具而不是替代人。争议主要来自营销过头、预期失真，以及大家对 AI 在复杂代码库里到底能做到什么的理解差异。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
讨论里反复提到，AI 漏洞研究的影响不止在开源，closed source 和反编译后的 binary 也可能被同样的方法扫描。有人担心 nation state 和其他攻击者会把这类能力放大成大规模 0-day 搜索，而补丁部署速度跟不上。也有人说，LLM 对源代码里的命名、注释和训练语料更敏感，但配合 Ghidra（逆向工程工具）、objdump（查看二进制指令的工具）这类工具时，对二进制和旧程序同样能挖出语义。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14]
真正的运营问题是 slop 和 review 负担：模型会生成大量漏洞报告和 PR，维护者必须先 triage，再决定哪些值得看。评论里有人提到，Linux kernel 的维护者最近确实因为 AI 报告激增而扩充人手，但也有项目开始只允许少数可信贡献者提交 AI 产物。成本争论则分成两边：一边认为 tokens 便宜，另一边强调 agentic task 会吃掉大量 token，企业还得算人工审查、生产率和安全责任。换句话说，问题不是能不能跑模型，而是谁来承担筛选和验证的成本。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14] [来源15] [来源16] [来源17]
false positive: 误报；报告里看起来像漏洞，但实际上不可复现、不可触发或不构成实际问题。
static analysis: 静态分析；不运行程序，直接分析源码、控制流和数据流来找缺陷的方法。
fuzzing: 模糊测试；用大量变异输入反复刺激程序，借崩溃和异常行为寻找漏洞的测试方法。
PoC: Proof of Concept，概念验证；用于证明漏洞确实可触发的最小复现或利用代码。
triage: 漏洞分诊/筛选；对大量报告做验证、去重、定级，判断是否真实和严重的流程。