2026 年 6 月 1 日，Linux 内核加密子系统的维护者 Eric Biggers 在提交 AF_ALG 废弃补丁时，在 commit message 里写下了这句话："LLMs have accelerated the rate the vulnerabilities are coming in。"同一天，Trend Micro 的 TrendAI 工具在 X.Org Server 里找到了 9 个新漏洞，xorg-server 21.1.23 和 xwayland 24.1.12 紧急发布。一天之内，Linux 生态里两个遗留接口各收到了 AI 驱动的安全账单，但结局完全不同。

copy.fail：一个专门为 AF_ALG 漏洞开的网站

Biggers 的补丁里有一个细节，在技术讨论里几乎被忽视：他引用了一个 URL——。这是一个真实存在的网站，提供一个能在大多数 Linux 发行版上可靠执行 root 提权的 Python 脚本，利用的正是 AF_ALG 接口的最新漏洞。

AF_ALG 是 Linux 内核的一个 socket 接口，允许用户空间程序通过 AF_ALG 套接字直接访问内核内置的加密引擎。设计初衷是让加密操作能够利用内核的硬件卸载能力——把 AES、SHA 等算法交给专用硬件加速器而不是在用户空间用软件实现。这是 2010 年代初期合理的设计：当时硬件加速器刚开始普及，在内核态统一管理加密后端被认为是高效的做法。

问题在于，AF_ALG 把内核加密引擎的接口暴露给了无特权用户空间——任何进程都可以通过 socket 调用访问。这是一个庞大的攻击面。Biggers 在补丁里的原话是："AF_ALG 几乎完全不必要，而它暴露的攻击面已经无法抵御现代漏洞发现工具的扫描。"

TrendAI 和 9 个新漏洞：X.Org 的另一份账单

同一天，Trend Micro 的 AI 安全研究工具 TrendAI（Zero Day Initiative）向 X.Org 项目提交了安全报告。9 个新漏洞，8 个来自 TrendAI，第 9 个由 Red Hat 的 X.Org 输入子系统开发者 Peter Hutterer 独立发现。漏洞覆盖范围从 XKB 键映射处理器的栈溢出，到 XSYNC 的三处 use-after-free，到 GLX 的越界读写，到 DRI2 缓冲区接口的越界写。

xorg-server 21.1.22 刚因五个安全漏洞发布修复版本；21.1.23 紧随其后，修的是这 9 个。X.Org 安全问题的密度在提升。

这不是 X.Org 第一次被安全研究者描述为灾难。超过十年前，已有安全研究者公开指出 X.Org 的安全状况"比看起来更糟"，认为其代码库从结构上就不适合运行在高权限环境下。十余年过去，漏洞还在来，只不过现在是 AI 在批量找。

为什么 AF_ALG 可以废弃，而 X.Org 只能继续打补丁

两个接口同时面对 AI 加速的漏洞发现，但应对策略截然不同。AF_ALG 进入废弃流程，X.Org 继续发补丁。这不是维护者的偏好差异，而是两个接口在用户基础上的根本区别。

AF_ALG 的实际用户几乎为零。Biggers 在补丁里直接说："付出的维护努力与实际使用它的程序数量极不匹配，而那些程序换成用户空间实现会更好。"Linux 7.2 里 AF_ALG 的零拷贝支持已经先行移除（安全原因），硬件卸载支持也被删除，理由是"使用 off-CPU 加速器有巨大的性能和攻击面开销，我从未见过实际使用 AF_ALG 加速器比用户空间软件加密更快的案例"。剩下的 AF_ALG 只保留纯软件实现路径，等待最终删除。

X.Org 的情况则不同。尽管 Wayland 已经是新系统的默认显示协议，但 X.Org 在大量存量系统、企业桌面、嵌入式设备上仍然活跃运行。XWayland——在 Wayland 下运行 X11 应用的兼容层——也继续依赖 X.Org 的代码库。删除 X.Org 意味着打破数以千计的软件和使用场景，这在工程上不可行。所以 X.Org 的路径只能是：打补丁、发版本、重复。

漏洞发现速度 > 修复速度：AI 引入了新的维护方程

Biggers 的 commit message 里那句"LLMs accelerated the rate the vulnerabilities are coming in"，不只是一个技术观察，而是一条警告：AI 安全工具正在改变漏洞发现和漏洞修复之间的速率平衡。

传统上，漏洞发现是一个人工密集的过程——安全研究者需要理解代码逻辑、构造输入、验证利用路径。这限制了漏洞发现的速度，同时也给维护者留出了相对充裕的修复窗口。当 AI 工具（无论是形式验证增强工具、LLM 辅助代码分析还是专用 fuzzer）开始介入后，这个平衡被打破：一批历史上被认为"太老、太复杂、人工审计成本太高"的代码库，正在被批量扫出问题。

这对遗留系统的维护者来说，是一个新的结构性压力。不是因为代码变得更危险了，而是因为代码里一直存在的危险变得更容易被发现。AF_ALG 的漏洞并非在 7.2 开发周期里新引入的——它们在代码里存了多年，只是现在被找到了。

两种结局，同一个信号

AF_ALG 废弃和 X.Org 打补丁，从表面上看是两个独立的安全事件，但它们指向同一个问题：当 AI 工具开始系统性地清查遗留代码库时，维护者必须在"持续修复"和"彻底废弃"之间做出选择，而做出这个选择的依据是用户基础是否存在，不是代码的安全质量。

有用户的接口只能打补丁，没用户的接口才能废弃。这个逻辑会让漏洞密集、用户又无法放弃的代码库长期处于一种"只能维持"的状态——不能废弃，打补丁的速度也跟不上 AI 发现的速度。

Phoronix 的报道最后说，"有趣的是看今年夏天 AI 会在 X.Org Server 里再挖出多少问题"。