刚刚爆了一个影响 17 年后所有 Linux 内核的本地提权漏洞 CVE-2026-31431 / Copy Fail，尽快排查

2017 年后还是从现在开始 17 年之后？

@wfg #1 2017 H2 引入的漏洞

@ggdxwz 我看见第一眼以为是 17 年后才会有问题......那样的话就不管了

呃，运维要忙死了

测试了几个新的系统,都给攻破了,老旧的系统竟然没有事

@arfa #5 我试了一下，ARM 开发板好像没事，HN 评论说目前 Payload 是针对 x86_64 的，但其他架构改改就能用

目前能想到一个危害是，现在很多 AI agent 是以非 root 用户运行的，如果 agent 被投毒，利用此漏洞可以直接提权到 root 。
还有就是，配合其他远程访问漏洞，比如 nginx 如果有漏洞，本来是 www-data 用户的权限，可以提升至 root 。

@villivateur #7 是这样的，就像一个放大器。Agent 投毒一个中转站就能实现，甚至中转站供应链出问题都有极大风险

以防有人需要，源站上写了临时解决方案，就是临时禁掉 algif_aead 核心模块。

```bash
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null
```

总结
该脚本的目的是在系统上创建一个后门，可能是通过修改 su 命令文件来获得 root 权限。
利用网络套接字（ socket ）和一些加密伪装，隐藏了与远程主机的通信。
通过修改关键的系统文件，特别是 su ，它能够使攻击者获得管理权限。

隐藏的后门分析：

通过修改 /usr/bin/su ，攻击者可以在没有用户知情的情况下获取 root 权限。
套接字部分可能与远程控制服务器通信，允许攻击者远程执行命令。
可能通过网络连接执行其他命令或传输敏感数据。

结论：这段代码显然是恶意的，试图在系统中安装后门，并且可能被用于进一步控制目标系统。

好离谱

打完补丁安心出去玩

还好是五一前，五一发漏洞都得炸了

17 年现在才被发现？

以防你想问：不，大部分 Android 手机禁用了 algif_aead 等内核模块，因此可能不能利用这个漏洞提权。

@andlp 换个好点的 ai 吧。。
1. 核心触发原语：AF_ALG 与特定加密算法
脚本开头使用了 a = s.socket(38, 5, 0)。其中 38 对应的是 AF_ALG （ Linux Kernel Crypto API 的用户态接口）。
接着它绑定了特定的加密算法：a.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))。
algif_aead 是内核中处理 AEAD （认证加密）的核心模块。
authencesn 是一种用于 IPsec 的加密包装器，它需要处理扩展序列号（ ESN ）。在计算 HMAC 时，它需要对序列号的字节进行重新排列，这会导致它在目标缓冲区中执行一次 4 字节的临时写入（ Scratch Write ）。
2. 内存越权：splice 与页缓存投毒
脚本中使用了 os.splice （对应 C 语言的 splice() 系统调用）。splice 可以在两个文件描述符之间移动数据，而不需要将数据复制到用户空间（即零拷贝）。
在这个 payload 中，攻击者通过 splice 将目标文件（这里是高权限的可执行文件 /usr/bin/su ）映射到了加密套接字（ Socket ）的内存空间中作为“密文”输入。
漏洞的致命点在于：algif_aead 模块在执行加密操作时，默认是 “原地操作”（ in-place ） 的（即源缓冲区和目标缓冲区是同一个）。当输入数据是通过 splice 从普通文件映射过来时，目标散列表（ Scatterlist ）实际上直接指向了该文件在内核中的 页缓存（ Page Cache ）。
3. 利用过程：积少成多的 4 字节写入
当脚本调用 u.recv() 触发解密操作时，底层的 authencesn 算法会将攻击者通过 sendmsg 传入的 4 字节序列号（ seqno_lo ，即 payload 中的恶意指令片段），直接覆盖写入到由于原地操作而共享的“目标缓冲区”中。
因为目标缓冲区就是 /usr/bin/su 的页缓存，这就导致内核的只读页缓存被直接篡改了 4 个字节。
payload 中的 while i<len(e): c(f,i,e[i:i+4]); i+=4 是一个循环。它将一大段经过 zlib 压缩的 Shellcode （提权恶意代码）解压后，每次 4 个字节，利用上述机制一点点“缝合”进内核中 /usr/bin/su 的内存映像里。
4. 提权执行
当 4 字节循环写入完成后，内核中缓存的 /usr/bin/su 已经被注入了恶意的 Shellcode 。
此时脚本执行 g.system("su")。由于 Linux 内核会优先从页缓存中读取文件执行，加上 su 本身带有 setuid 属性（执行时拥有 root 权限），被投毒的 Shellcode 就会以 root 权限运行，从而完成提权
------
3. Linux 本该有的保护机制去哪了？（漏洞的真正命门）
是的，Linux 有一个极其核心的机制：内存权限控制（ Memory Management Permission ）。
在这个漏洞场景中，攻击者是用只读（ Read-Only ）权限打开的 /usr/bin/su 。
按照 Linux 正常的逻辑，当 authencesn 算法试图把那 4 字节的脏数据写到 /usr/bin/su 的页缓存时，内存管理系统（ MM subsystem ）应该立刻跳出来大喊：“停下！这个页面是只读的！”然后触发一个缺页异常（ Page Fault ），直接把操作干掉，甚至把当前的进程杀掉（ Segmentation Fault ）。
如果这个机制生效，那 4 字节根本写不进去！
那为什么没生效呢？这恰恰是这个漏洞（ CVE ）最核心的代码 Bug 所在：
内核的 algif_aead 模块在处理 splice 传过来的内存页（ Page ）时，它底层调用的是 kmap_atomic 之类的底层函数去直接映射物理内存。
这个底层的写入操作绕过了 VFS （虚拟文件系统）的写权限检查，也绕过了正常的 Copy-on-Write （写时复制）机制。它盲目地假设：“既然你把这个缓冲区指定为加密/解密的输出目标（ dst ），那它一定在前面已经被检查过是可写的了。”

@zxp 可能会导致代理出问题

五一劳动节，劳动个不停，真应景了

@blackmirror #18 至少没有放假那几天说，收到消息赶紧远程把补丁打了

能通过 apt 打补丁吗

@andlp #10 你这是哪门子的 AI ，牛头不对马嘴的

我试了 debian13 和 ubuntu 2404 都可以提权

@cnevil #16
@HFX3389 #21
也有可能是上下文的问题
我用 gemma 4 E4B Q4_K_M 完全离线的情况来说
只丢 poc 的 code 总结出来就类似 @andlp #10
把 https://xint.io/blog/copy-fail-linux-distributions 内 "The Root Cause: Page Cache Pages in the Writable Scatterlist"到"The Exploit"这几段乱的内容+poc code 丢进去
总结出来的就是正确的:
执行： 所有 Shellcode 片段都被写入后，g.system("su") 执行。由于 /usr/bin/su 的 Page Cache 已经被 Shellcode 覆写，当 su 被载入执行时，它会执行攻击者植入的代码，并以 root 权限运行。