内核维护者怎么看 LLM 时代的安全

一份报告说，AI 在 Linux 内核里找到 79 个漏洞。

维护者逐条拆开，最后留下 10 个真实修复。按内核每小时合并十个半补丁算，这批成果约等于一小时开发量。

一、发生了什么

2026 年 9 月 21 到 23 日，Kernel Recipes 在巴黎开会。Linux 稳定内核维护者、内核安全团队成员 Greg Kroah-Hartman 做了一场 56 分钟的演讲，题目叫《Security in the LLM age》，录像 9 月 29 日上了会议频道。

这场演讲没有逐字稿，以下内容来自与会者笔记，几份记录的数字基本一致，措辞不是原话。

核心是一份账。某个自动化审计工具（代号 Mythos）声称在内核里发现 79 个漏洞。逐条核对的结果是：24 条除了"某个东西崩了"没有任何细节；14 条根本不是 bug；3 条数据是编的；15 条在最新版本里已经修好，其中 11 条是别人在报告出来之前就修完的。剩下约 20 条技术上成立，但大多带着前提：假设 root 挂载了恶意文件系统镜像、假设能在网络栈中间注入数据包、假设是很少人用的架构。

另一组数字更值得记住。内核现在每天发出约 33 个 CVE，一年前是每周 50 个。按版本算，6.9 到 6.19 每个约 500 个，7.2 超过 1500，7.3 可能到 2000。

真正让他担心的不是发现速度，是部署速度。从披露到被利用的平均时间，2018 年是 63 天，2020 年 32 天，2024 年 5 天，现在据他给出的数字是负 7 天。

补丁质量那一半也有实测。今年夏天他让阿姆斯特丹自由大学的六名研究生评审一批 LLM 生成的安全补丁，结论是大约一半"完全错"：打不上、修不了任何东西、针对不存在的问题，或者在文档化的威胁模型下根本不算安全问题。

二、跟你有什么关系

给开源项目提补丁的人。 你的报告会先被看"有没有说清怎么复现"。答不上来，对方没有义务替你查。

用 AI 做代码审计的团队。 瓶颈已经从"找"移到了"筛"。你的流水线要能在人看到之前先自己砍掉一半。

三、怎么用

1. 先测，再报。自己复现一遍，写清步骤和环境。不知道它怎么坏的，就不要提交。
2. 查历史，去重。那 79 条里有 15 条早就修了。提交前对一遍 git 记录和最新发布版本，这一步几乎不花时间，却能砍掉近两成噪声。
3. 把 changelog 删掉再看 diff。研究生就是这么做的：模型会把变更说明写得又长又自信，两行代码配七行注释。只看代码本身，判断会准很多。
4. 写清威胁模型。假设攻击者是 root、能网络注入，这类报告形式成立、实际不可用。先讲前提，别让对方猜。
5. 模型跑在本地。任何上传到托管服务的东西都可能变成公开的，未披露的漏洞尤其不能上传。

四、三个别信的说法

"AI 在内核里找到了 79 个漏洞。" 这是报告数，不是修复数。逐条核对后只剩 10 个真实修复，还有四分之一条目连细节都没有。看到"N 个漏洞"，先问过了几轮人工分诊。

"AI 生成的补丁一半是错的，所以这条路走不通。" 另一半是能用的。真正的问题是错误模式高度重复：把解锁函数换成销毁函数，因为"销毁"听起来更彻底；沿用几十年前的老写法；把已经废弃的模式又生成一遍。

"等模型再强一点，这些问题就没了。" 演讲里的判断是这波洪水还要 18 个月，也许 12 个月。模型变强会让发现更快，分诊压力更大。他把这轮比作六七年前的模糊测试浪潮：当时也是末日论一片，最后的解法是坐下来一条条修。rsync 用这些工具磨了几年，最新版本扫描已经干净。

五、一句话结论

AI 让"找到问题"变便宜了，于是"判断哪个值得修"成了唯一稀缺的东西。

信息来源

• Greg Kroah-Hartman – Security in the LLM Age（Kernel Recipes 2026 录像） 2026-09-29
• Greg Kroah-Hartman audits the 79 AI-reported Linux flaws: only ten were real（Ettayeb） 2026-10
• Security in the LLM Age 与会笔记（Sparse Notes） 2026-10

功能与价格以官方公告为准。本文写于 2026 年 10 月 22 日。