内核维护者谈 LLM 时代的安全

一份报告说，AI 在 Linux 内核里找到了 79 个漏洞。新闻标题到这里就结束了。

维护者拿到完整报告，一条一条看。最后能算作真正修复的，是 10 个。按内核每小时合并约 10.5 个补丁的速度，这差不多是一小时的正常产出。

一、发生了什么

2026 年 9 月 22 日，Linux 稳定版维护者 Greg Kroah-Hartman 在巴黎的 Kernel Recipes 会议上讲了《LLM 时代的安全》，录像已在会后发布，全长约 57 分钟。

核心案例是 Anthropic 的 AI 审计工具 Mythos 对内核的一次扫描。厂商公布的数字是 79 个漏洞。Kroah-Hartman 把报告拆开：

24 条只有一句「某处崩溃了」，没有任何细节；14 条根本不是 bug；3 条的数据是编的，他刻意不用「幻觉」这个词，因为那暗示背后有个主体；15 条在最新版本里已经修好，其中 11 条是别人在报告发布前就公开修掉的，工具只是把邮件列表扫了一遍。

剩下的里面，7 条要求攻击者能以 root 挂载恶意文件系统，2 条假设能在协议栈中间注入数据包，6 条是认证电信网络里的 SCTP 问题，2 条是轻微的 IPv6 问题，1 条需要本地恶意用户且能访问 GPU。真正需要修的约 20 条，最终计为 10 个真修复。

同场还有两个数字更值得记。内核 CVE 的签发量从一年前的每周约 50 个，涨到现在的每天 33 个。从披露到被利用的平均时间，2018 年是 63 天，2020 年 32 天，2024 年 5 天，现在到了负 7 天——攻击者跑在补丁前面。

内核这边也在改流程。各个子系统开始把威胁模型写下来；报告者被要求直接抄送维护者，别只发给安全列表；比起「我发现了问题」，维护者更希望收到「这是补丁」。他还加了一条硬规定：drivers/staging 目录不再接受 LLM 生成的补丁，除非提交者手里有对应硬件并实测过。理由是，这个目录本来就是教人做内核开发的地方，不是刷提交数的地方。

二、跟你有什么关系

用 Linux 的。 稳定版更新不是可选项。负的利用时间意味着「等别人先被打」这套策略失效了。

做安全工具的。 报告的原始数量不是产品指标。客户真正买的是通过人工复核的比例，以及每个专家小时筛出多少真问题。

给开源项目提报的。 未经验证的批量报告会消耗维护者信任。信任没了，你后面提的真问题也会被一起忽略。

三、怎么判断一份 AI 审计报告

1. 先问快照版本。 报告是基于哪个 commit 跑的？有没有和最新发布比对过？那 15 条「已修复」里，11 条本来可以靠一次 git 查询排除。
2. 看威胁模型。 「需要 root 挂载恶意镜像」在形式上成立，在工程上通常不算安全问题。内核安全团队对这类报告有固定回复。报告里这类条目占比越高，含金量越低。
3. 要求复现步骤。 Kroah-Hartman 夸过的一点，是对方搭出了 RISC-V 虚拟机、测试用例和复现脚本。能复现的条目，才值得排期。
4. 把变更日志删掉再看补丁。 他让 6 名阿姆斯特丹自由大学的研究生审过一批 LLM 生成的补丁，约一半是错的：不适用、没修到点上、修的是不存在的路径，或者按文档化的威胁模型根本不算安全问题。生成的补丁往往带超长说明和成堆注释，两行代码配七行解释。先删说明，只看 diff。
5. 看它有没有进上游。 补丁要过编译、过回归、过维护者。只在本地跑通的「修复」，价值接近于零。

四、三个别信的说法

「AI 找到了 79 个内核漏洞。」 这是报告条数，不是漏洞数。经过维护者复核，真修复是 10 个。看到这类数字，第一个问题应该是「被接受的比例是多少」。

「误报多点没关系，反正能筛。」 维护者的时间就是成本。Coverity 的历史是：开发者对超过 20% 的误报率就不买账，50% 的误报率卖不动。AI 审计也一样。

「把代码传给云端模型分析很方便。」 他明确警告：传上去的东西会流到别人那里。安全列表里经常有人抱怨，自己的「发现」在公开前一天被别处报了出来。敏感代码只在本地跑。

五、一句话结论

生成漏洞报告已经很便宜，判断哪一条值得修仍然很贵；AI 把瓶颈从「找」挪到了「审」，而审的那一端没有变快。

信息来源

• Security in the LLM age，Kernel Recipes 2026，讲者 Greg Kroah-Hartman，2026 年 9 月 22 日
• Security in the LLM Age（Kernel Recipes 2026 演讲整理），Sparse Notes，2026 年 10 月 3 日

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