732字节的”优化”，撬开了整个Linux的root权限
一个优化代码的小举动，埋了颗定时炸弹，九年后才炸。
2026年4月29日，安全研究团队Xint Code披露了一个Linux内核高危漏洞，编号CVE-2026-31431，代号”Copy Fail”。攻击者只需要一个732字节的Python脚本，在一台低权限的Linux机器上运行，就能直接拿下root shell。成功率：接近100%。无门槛，无版本依赖，跑就跑。
这个漏洞的发现，让安全圈集体沉默了几秒。
它是怎么进来的
故事要从2017年讲起。
那一年，内核开发者在优化AF_ALG加密接口的性能时，做了一个看似无害的改动：将AEAD解密操作的源缓冲区（source Scatterlist）和目标缓冲区（destination Scatterlist）设置为相同地址。这是一个纯粹的性能优化——让解密操作直接复用同一块内存，少一次复���。
没有人觉得有问题。代码跑了好几年，没出过事。
直到有一天，有人把AF_ALG加密接口、splice()系统调用和内核页缓存（Page Cache）机制放在一起看，发现这三个东西撞了车。
具体来说：当splice()把一个只读文件的内容通过AF_ALG接口送入内核进行AEAD模式解密时，内核会将源缓冲区和目标缓冲区指向同一个地方——也就是那个只读文件的页缓存。解密时，authencesn算法会在缓冲区末尾追加4字节的序列号（序列号的作用是防重放攻击）。这4个字节，本应写入一块新分配的目标内存——但由于上述逻辑错误，它们直接写入了原本只读的文件缓存页。
只读文件，就这样被悄悄改了。
而内核执行时，读的是内存里的页缓存版本，不是磁盘上的原始文件。常规的杀毒软件、文件校验工具，扫的都是磁盘——磁盘上的文件完好无损，内存里的恶意代码正在被执行。
这就是”Copy Fail”这个名字的由来：内核本意是”复制失败了，数据原路返回”，结果却把数据写进了本不该写的地方。
为什么这次不一样
Linux内核提权漏洞并不罕见。安全圈有句老话：没有绝对安全的系统，只有还没被发现的漏洞。2016年的Dirty Cow（脏牛）、2022年的Dirty Pipe（脏管道），都是让人头皮发麻的本地提权漏洞。
但Copy Fail在三个维度上碾压了前辈：
第一：门槛低到离谱。
Dirty Cow依赖复杂的竞态条件，一个内核线程必须和另一个精确配合，才能在特定时机写入目标文件。新手跑，失败；老手跑，有时成功有时失败。Dirty Pipe好一些，但仍有版本限制，需要特定的编译条件。Copy Fail：不需要竞态，不需要精确时机，不需要特殊内核模块，一个普通用户账号，跑，跑完就是root。
第二：成功率接近100%。
���究者在Ubuntu 24.04、Amazon Linux 2023、RHEL 9、SUSE Linux Enterprise Server 15四大主流发行版，以及Linux内核6.12、6.17、6.18三个版本分支上逐一实测，每次都稳定拿到root shell。甚至连WSL2（Windows Subsystem for Linux 2）子系统也未能幸免——在Windows上跑Linux环境的开发者，同样受影响。
第三：静默写入，不留痕迹。
磁盘文件完好无损，md5sum校验通过，常规监控工具全部失灵。内核读的是被篡改过的页缓存版本，整个提权过程对系统日志零污染——攻击完成后，攻击者已经在root shell里，系统日志才开始记录，录的是root干的合法操作。
它的杀伤半径
Copy Fail影响的不是某个特定软件版本，而是2017年以来所有未打补丁的Linux内核，涉及版本之广、数量之多，让它成为近年来覆盖面最大的Linux内核提权漏洞之一。
攻击链路简单清晰：
普通用户账号 → 跑732字���Python脚本 → 篡改/usr/bin/su的页缓存版本 → 执行su → 获得root shell
一个低权限用户，一台普通Linux服务器，跑完脚本，就能把整台机器变成他的。
更让云原生运维崩溃的是：这个漏洞天然支持容器逃逸。
容器本质上是对宿主机内核的共享调用。一个容器内的低权限攻击者，通过Copy Fail篡改宿主机上的可信二进制文件，可以在宿主层面直接获得root权限——容器边界被彻底穿透。这意味着云服务商、企业的Kubernetes集群，只要有一个容器被攻破，攻击者就能以此为跳板拿下整台宿主机，再横向渗透进集群内的其他节点。
在云原生时代，这个漏洞本质上是一颗覆盖整个集群的定时炸弹。
修复与缓解
漏洞披露当天，Linux内核团队已发布修复补丁，提交号a664bf3d603d。修复思路很简单：回退2017年的那处优化代码——当时为了少一次复制埋下的隐患，现在用一次复制换回来。
主要发行版也在紧急推送内核更新：
- Ubuntu已通过内核更新推送修复
- Red Hat已为RHEL系列发布安全公告
- SUSE已为SUSE Linux Enterprise Server和openSUSE推送更新
- Amazon Linux已发布ALAS安全公告
对于暂时无法重启内核更新的生产环境，有两个临时缓解措施：
方案一：禁用algif__aead内核模块
echo "blacklist algif_aead" > /etc/modprobe.d/blacklist.conf
AF_ALG接口是漏洞的入口，关掉它，漏洞链路自然断裂。但部分加密应用依赖AF_ALG，禁用前需确认业务是否受影响。
方案二：配置seccomp策略，阻止AF_ALG套接字创建
在容器层面限制系统调用权限，防止攻击脚本打开AF_ALG套接字，可以阻断攻击路径。
一颗埋了九年的”优化”
Copy Fail最值得深思的地方，不在于它的技术复杂性，而在于它的起源。
2017年的那位开发者，做了一个完全合理的性能优化——少一次内存复制，让加密解密操作快一点点。任何代码审查都会批准，没有人会拒绝。那一年，没有人能预见这个优化会和splice()系统调用以及内核页缓存形成这样的连锁反应。
这是架构级安全风险的典型样本：单个来看完全正确、局部来看完全合理的代码，放在一起，产生了灾难性的后果。
安全研究者Xint Code在漏洞公告中说了一句话，大意是：
写这个漏洞的人没有做错任何事。这是一个系统性风险，是我们构建复杂系统时必然会积累的隐性债务。九年后它被发现，不是谁的疏忽，是系统复杂度的必然结果。
当Linux内核积累了上亿行代码，当一个简单的优化可以通过20层调用链触碰到20个不同的子系统，没有人能看清全局。Copy Fail是一个关于复杂系统的隐喻，也是一声迟来的警钟。
如果你跑着Linux服务器，现在该做一件事：检查内核版本，确认是否在2017年以后的范围内。如果是，打补丁，或者用上面的方案缓解。732字节不多，但留给攻击者的时间窗口，正在关闭。
信息来源