AI 补丁禁令与 13 年老漏洞:Linux 内核一个不太平的夏天

内核社区正在 AI 浪潮中重新定义边界

---

一、Greg KH 的"健身房"规则

8 月 3 日，Linux 内核二号人物 Greg Kroah-Hartman 在邮件列表上发布了一条新政策：drivers/staging/ 子系统将自动拒绝 LLM 生成的补丁。

表面上看，这是一条针对 AI 补丁的禁令。但 Greg KH 的解释比"反 AI"要微妙得多。

drivers/staging/ 是内核中的"新手训练场"。这里存放着大量半成品驱动——代码质量不高，远未达到主线标准，但恰恰因为如此，它成了新人学习内核开发的天然入口。新人可以在这里修复代码风格问题、清理 API 调用、做低门槛的贡献，在真实维护者的指导下成长。

"我们不需要用 LLM 来"修复"这里的代码风格问题，"Greg KH 在公告中写道，"如果真想清理，明天就能做完。但那就完全违背了 staging 存在的意义。"

Greg KH 本人并非 AI 反对者。他曾在内核开发中使用 AI 工具（他自己的"Clanker 2000"工具），并取得了实际效果。但 staging 区的特殊性让他划出了一条清晰的红线：AI 可以辅助，但不能取代学习过程。

他特别强调，LLM 生成的补丁"非常容易被识别"，所以不要试图隐瞒。对于真正有效的安全修复，政策留有例外——但提交者必须在真实硬件上测试，并给出详细的测试说明。

Linus Torvalds 随后也表态支持这一方向。他在 7 月底的采访中重申，Linux 内核"不是反 AI 的"，AI 是有用的工具，但内核社区"不是社会正义项目"，代码质量和技术判断始终是第一位的。

二、AI 助手的双刃剑

就在 Greg KH 发布新政策的同一天，Phoronix 报道了一个令人深思的数据：Linux 7.2 开发周期中，29% 的代码提交包含 "Fixes:" 标签——这意味着近三分之一的补丁是在修复之前补丁引入的问题。

内核开发者 Tony Luck 指出，AI 机器人可能是这一现象的主因。这些机器人正在大量发现小 bug，驱动着源源不断的微小修复。这解释了为什么 7.2-rc6 成为了"史上最大 RC6"——Linus Torvalds 在发布邮件中直言"This RC is huge"，commit 数量创下了 RC6 阶段的历史纪录。

AI 机器人在发现 bug 方面确实高效。但问题在于：修复的质量参差不齐。 Greg KH 的另一句话值得深思："即使是最好的 AI 工具，也有至少 1/3 的修复结果是完全错误或有害的。"

这不只是 Linux 内核独有的挑战。8 月 5 日，Rust 语言项目也正式通过了 LLM 使用政策。Rust 核心团队在博客中详细解释了为什么需要规则：AI 生成的补丁不再代表"付出努力和理解"，一篇格式漂亮的 PR 背后可能没有一个真正理解代码的人。Rust 项目当前有 1281 个未关闭的 PR，审核压力本已巨大，AI 补丁洪流让情况雪上加霜。

Rust 的政策同样不是全面禁止，而是要求明确标注 AI 生成内容，禁止在关键区域（如 diagnostics、soundness）使用 AI 生成代码，并禁止机械式地将 reviewer 意见粘贴到 LLM 再粘贴回来。

三、OVSwrap：AI 发现的安全盲区

就在社区讨论 AI 是否应该写内核补丁的同时，安全研究员 Asim Manizada 公开了一个 13 年历史的 Linux 内核漏洞——OVSwrap（CVE-2026-64531，CVSS 7.8）。

这个漏洞的发现过程本身就极具戏剧性。Manizada 正是那位此前用 LLM 发现 CIFSwitch 漏洞的研究员。这一次，他给 LLM 配备了一个"几何推理工具"——让模型在分析内存布局时保持 ASCII 图表的状态，逐步追踪堆和分配器的结构。结果，模型在 Open vSwitch 的内核数据路径中发现了一个隐蔽的整数截断问题。

技术细节是这样的：Open vSwitch 从用户空间接收"动作"列表，然后将其扩展为更大的内部格式。这些内部动作存储在 Netlink 属性中，其长度字段只有 16 位宽。理论上，单个嵌套属性的总长度不能超过 64 KiB。但内核代码此前从未检查这个限制。

这个 bug 在代码中存在了 13 年，但一直无法被实际利用——因为一个 32 KiB 的"总生成动作流"上限在无意中充当了防护。2025 年 3 月的一次变更移除了这个上限（原因是大型 OpenStack 部署中出现了不可预测的失败），使得旧漏洞突然变得可达。

攻击者可以构造一个合法的 CLONE 动作，在其中包含数百个小 conntrack 动作。内核扩展这些动作直到总长度超过 65535 字节，然后将其写入 16 位的 nla_len 字段——发生整数回绕。后续代码信任这个回绕后的长度，跳过它继续解析，实际上从攻击者控制的数据中间开始解析伪造的动作头，最终实现任意内核内存访问。

漏洞的影响面非常广。PoC（已于 8 月 5 日公开）支持约 800 个 x86-64 内核构建，覆盖 Debian、Ubuntu 22.04、Fedora、Arch Linux、Amazon Linux 2023、AlmaLinux、Rocky Linux、Kali Linux、Linux Mint、Pop!_OS、NixOS、Gentoo 和 openSUSE Tumbleweed。触发条件相当宽松——只需要一个非特权用户命名空间，不需要现有的 OVS 网桥，不需要 CAP_NET_ADMIN 在主机级别。

上游修复已于 7 月 24 日合入稳定树。如果你的发行版尚未推送补丁，应立即行动。

四、安全警报不止一个

OVSwrap 不是唯一的安全事件。同一周内，还有两个 Linux 内核漏洞进入了公众视野。

CVE-2026-53264（CVSS 7.8），一个位于 net/sched 包调度器中的 use-after-free 漏洞，允许本地用户执行任意代码并提权至 root。发现者是 Star Labs 的研究员 Lee Jia Jie，他在 TyphoonPWN 2026 安全竞赛中猎到了这个 bug。PoC 已在 GitHub 公开，在 CentOS Stream 9 上测试可在数秒内完成提权，但攻击需要特定的时序窗口（race condition）。

Bridge STP 实现中的 use-after-free 则由两名独立安全研究员在 TyphoonPWN 2026 期间提交。该漏洞位于 Linux 内核网桥的生成树协议实现中，同样可能导致本地提权。

一周之内，三个高危内核漏洞被公开。即使其中两个的攻击面比 OVSwrap 窄，但"三天三漏洞"的节奏仍然让安全团队面临巨大压力。

五、内核在 AI 时代的分裂

如果把这一周的消息放在一起看，一条清晰的线索浮现出来：AI 正在从两个方向重塑 Linux 内核开发——既在加速 bug 发现，也在制造噪声。

一方面，AI 工具发现了 OVSwrap 这样的隐蔽漏洞，展示了 AI 在安全研究中的价值。Manizada 的方法（给 LLM 配备几何推理工具）代表了一种新的漏洞发现范式，可能在未来几年内显著改变安全研究的效率。

另一方面，AI 生成的补丁洪流正在淹没 staging 区，迫使社区做出"不欢迎 AI 贡献"的决定。Rust 项目的 1281 个未关闭 PR 是另一个警示信号——代码生成能力远快于代码审查能力，这个失衡是许多大型开源项目共同的挑战。

Linux 内核社区的选择是务实的：不拒绝 AI 工具，但拒绝不加区分的 AI 输出。 Greg KH 的"健身房"比喻很贴切——staging 区是锻炼的地方，AI 举重机不能替新手做深蹲。而安全漏洞的发现，则恰恰需要 AI 在"真正需要力量的地方"发挥作用。

这个夏天，Linux 内核注定不会平静。7.2 的最终版本预计在 8 月下旬发布，届时我们或许会看到更多关于 AI 在开源开发中定位的讨论。

一句话总结

Linux 内核在 AI 浪潮中既受益又承压：AI 发现了 13 年的老漏洞，也带来了必须挡在 staging 区外的补丁洪流。