732字节，Root权限，还有9年的潜伏期
一段732字节的Python代码，就能让普通用户变成root。
不需要编译，不需要依赖，不需要碰运气。从2017年到2026年，整整九年，几乎所有Linux发行版都敞开着这扇门。更可怕的是——它修改的是内存，不是硬盘，所以你被黑了，磁盘取证却显示一切正常。
这就是Copy Fail（CVE-2026-31431）。一个让安全圈瞬间清醒的名字。
它不写入磁盘，所以几乎无法发现
传统的入侵会留下痕迹。篡改系统文件？磁盘上的哈希值会对不上。但在Copy Fail面前，磁盘永远是干净的。
漏洞的核心藏在Linux内核的algif_aead模块里。当你用splice()系统调用把文件内容送进加密接口时，内核本该把数据拷贝到用户缓冲区处理。但2017年的一次"优化"让代码偷懒了——它直接在页面缓存（page cache）上动手脚。
页面缓存是什么？是内核把磁盘文件缓存在内存里的副本。你运行/usr/bin/su时，CPU读的是内存里的这份拷贝，不是硬盘。
Copy Fail利用AES-256-GCM认证加密的一个逻辑错误，往页面缓存里精准写入4个字节。这4个字节刚好能篡改setuid二进制文件的指令流。于是，当你执行一个原本正常的系统命令（比如su），它实际上在执行攻击者植入的代码。
没有磁盘IO，没有文件修改时间变化，没有inotify事件。 只有内存里的页面被污染了。一旦系统重启或者内存被回收，脏页面消失，证据也随之蒸发。 forensic镜像显示一切正常，但你的服务器早已沦陷。
比Dirty Pipe更脏，比Dirty Cow更稳
Linux内核不是第一次爆出本地提权漏洞。但Copy Fail的可怕在于它的确定性。
Dirty Pipe（2022年）需要内核5.8+，Dirty Cow（2016年）需要竞争条件（TOCTOU），成功率看运气，偶尔还会把系统搞崩溃。
Copy Fail呢？
| 特性 | 典型Linux LPE | Copy Fail |
|---|---|---|
| 竞争条件 | 必需 | 不需要 |
| 发行版特定偏移 | 必需 | 不需要 |
| 成功率 | 30-80% | 100%，单次执行 |
| 影响窗口 | 窄版本范围 | 2017→2026（9年） |
一段脚本，Ubuntu、RHEL、Amazon Linux、SUSE通杀。不用改偏移，不用重新编译。它要么成功，要么不成功——而它总是成功。
更狠的是跨容器逃逸。页面缓存是主机内核共享的资源。你在一个容器里执行攻击，污染的是宿主机的页面缓存。这意味着Kubernetes集群、多租户CI/CD Runner、沙箱环境——只要共享内核，就共享了漏洞。
但厂商说："中等严重性"
按理说这种级别的漏洞应该引发红色警报。但现实有点荒诞。
Red Hat把CVE-2026-31431标记为**"Moderate severity"（中等严重性），修复状态是"Fix deferred"（延迟修复）**。Debian、Ubuntu、SUSE的跟踪页面也透着一股不紧不慢的气息。
为什么？因为这是个"本地"漏洞。需要先在系统上有个普通用户权限才能触发。
但这逻辑在今天站得住脚吗？ 云原生时代，容器逃逸就是新的边界突破。一个通过Web RCE拿到的低权限Shell，配合Copy Fail，就是宿主机的root权限。CI环境里跑个恶意PR，整个构建农场沦陷。
当攻击链变得廉价时，本地提权就是远程攻击的最后一环。把Copy Fail降级处理，就像说"只要小偷进了门，让他拿到保险箱钥匙也没关系"一样离谱。
AI用了一小时，人类用了九年
这个漏洞的发现过程本身就像科幻片。
研究团队Xint的人类研究员Taeyang Lee先有了灵感：splice()把页面缓存页交给加密子系统时，散集列表（scatterlist）的页来源是不是被忽视了？
然后，Xint Code登场了。这是他们的AI安全审计工具。一个提示词，一小时扫描，整个Linux crypto/子系统被翻了个底朝天。Copy Fail是这次扫描中最高危的发现。
九年里，无数双眼睛看过这段代码。人类审计员、自动化工具、内核维护者——都没发现问题。AI用了一小时。
这不是要渲染AI威胁论，而是一个冷酷的事实：传统代码审计已经跟不上复杂系统的漏洞密度了。 当内核代码累积到千万行级别，人类擅长的直觉和AI擅长的规模扫描，必须结合起来。
现在该做什么
如果你跑的是多租户Linux、共享内核的容器、或者执行不可信代码的CI环境——立刻打补丁。
补丁是mainline commit a664bf3d603d，它回滚了2017年的那次"优化"，让req->src和req->dst重新分离。大多数主流发行版已经推送更新。
在补丁到位前，可以临时禁用algif_aead模块：
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true
对绝大多数系统来说，这不会影响功能——dm-crypt/LUKS、OpenSSL默认构建、SSH、IPsec都不走AF_ALG接口。只有显式配置使用AF_ALG的应用会回退到用户态加密库。
对于不可信工作负载（容器、沙箱），无论是否已补丁，都应该用seccomp阻断AF_ALG套接字创建。
个人笔记本用户风险较低，但也建议更新。毕竟732字节的脚本，可能比你的锁屏密码还短。
当攻击变得如此轻巧，防御就不能再沉重缓慢。 九年足够长了，不是吗？
【锐评】：Red Hat把能100%提权且潜伏9年的内核漏洞标为"中等严重性"，这种风险评估还停留在单机时代，仿佛云原生环境的容器逃逸只是"本地问题"——要么是傲慢，要么是脱节。
参考链接：
https://copy.fail/