一个仅732字节的Python脚本，无需竞争条件、无需重试、不修改磁盘，即可在2017年至今的几乎所有主流Linux发行版上稳定获取root权限。这不是在拍电影，这是CVE-2026-31431，代号Copy Fail。
🔷 已知受影响发行版：Ubuntu 24.04 LTS、Amazon Linux 2023、RHEL 8/9/10、SUSE 16、Debian、Arch、Fedora、Rocky、AlmaLinux等主流发行版几乎全部中招。另据第三方安全团队人工验证，国产信创生态中UOS（1070/1060）、银河麒麟V11/V10、openEuler 24.03 (LTS-SP1)、CTyunOS V4.0、Anolis OS 8.9、OpenCloudOS 9.4、NewStartOS 6.06、Oracle Linux 10.0、Debian 13等均确认受影响；Ubuntu 17.04、RHEL 7.9、CentOS 7、CUOS 4等早期或特定版本经测暂不受影响。
🔷 官方修复提交：a664bf3d603d（主线）、fafe0fa2995a（6.18.22）、ce42ee423e58（6.19.12）
Copy Fail的恐怖之处，不在于某个愚蠢的缓冲区溢出，而在于三个各自设计合理的内核机制，在特定组合下产生了作者未曾预料的化学反应。这种“逻辑缺陷型”漏洞比传统的内存破坏更难被发现，却也更加稳定可靠。
这三个机制是：
IPsec扩展序列号支持里的一个“临时借用缓冲区”的优化。
三者叠加的结果：一个普通用户，能把任意只读文件（包括/usr/bin/su这样的 setuid-root 程序）的页缓存页面，链入一个"可写"的内核scatterlist，然后由内核加密算法本身，向这个页面写入4个受控字节。
听起来有点绕？没关系，下面我们从代码层面一层层拆开。
AF_ALG与algif_aead的in-place“优化”
Linux内核的Crypto API提供了一个面向用户态的套接字接口AF_ALG，允许应用程序通过标准socket系统调用（socket() → bind() → sendmsg() → recvmsg()）使用内核内置的加密算法。这本来是个好事——用户态不用自己实现AES、SHA等算法，也便于FIPS合规场景使用经认证的加密实现。
algif_aead是AF_ALG中负责AEAD（Authenticated Encryption with Associated Data）算法的模块。AEAD是一种同时提供机密性和完整性的加密模式，例如GCM、CCM，以及这里涉及的IPsec常用的 authencesn(hmac(sha256),cbc(aes))。
2017年，commit 72548b093ee3引入了一个“性能优化”：在解密路径上，尝试做in-place（就地）操作，即让req->src==req->dst，源缓冲区和目标缓冲区指向同一块内存。意图很朴素——省一次内存拷贝，提升性能。
但这个优化忽略了一个关键事实：在algif_aead的上下文中，src和dst本来就来自不同的内存映射。src（TX SGL，发送端scatterlist）承载用户通过 sendmsg()发过来的AAD和密文；dst（RX SGL，接收端scatterlist）承载解密后的明文输出。强制把它们捏成“in-place”，不仅没带来实质性能收益，反而引入了大量复杂的状态管理。
而在解密路径上，内核为了“假装”in-place，做了这样一件事（详见algif_aead.c的_aead_recvmsg()）：
问题就出在这个“chain by reference”上。 如果tag数据恰好来自splice() 引入的文件页缓存页面，那么这些页缓存页面现在被链入了一个可写的destination scatterlist。
splice()是Linux的一个零拷贝系统调用，用于在两个文件描述符之间搬运数据，而数据无需经过用户态内存。它的常见用法之一是把文件内容直接"拼接"进一个管道。
splice(file_fd, pipe_wr, len) // 文件页缓存 → 管道
当splice的数据源是一个普通文件时，内核不会把文件内容复制到管道的内存缓冲区，而是直接把文件页缓存（page cache）页面的引用挂到管道的ring buffer里。这是零拷贝的核心机制——大家共用同一份物理页。
在AF_ALG的路径中，用户态可以这样构造：
01 打开/usr/bin/su（只读，任何人都能打开）；
02 用splice()把su文件的某一段内容“送”进AF_ALG操作的输入管道；
03 AF_ALG内部在处理时，会把这些来自文件页缓存的页面，作为tag区域链入RX SGL。
关键点来了：这些页面本来是只读的，但现在它们被挂在一个内核算法即将写入的scatterlist里。
authencesn的越界scratch write
authencesn是Linux内核crypto子系统中一个专门用于IPsec ESN（Extended Sequence Number，扩展序列号）的AEAD包装算法。IPsec的ESN使用64位序列号，但在网络线路上只传输低32位（seqno_lo），高32位（seqno_hi）由双方隐式维护。
在进行HMAC认证时，authencesn需要把这64位序列号按seqno_hi || seqno_lo的顺序排列后送入哈希运算。为了做这个重排，它在内部实现了一个“取巧”的做法——直接使用调用者提供的目标缓冲区（dst）作为临时scratch空间。
// crypto_authenc_esn_decrypt() 中的关键操作（简化）scatterwalk_map_and_copy(tmp, dst, 0, 8, 0); // 读取 AAD 8 字节scatterwalk_map_and_copy(tmp, dst, 4, 4, 1); // 用 seqno_hi 覆盖 dst[4..7]scatterwalk_map_and_copy(tmp+1, dst, assoclen + cryptlen, 4, 1); // 在 dst[assoclen+cryptlen] 写入 seqno_lo
前两步在AAD区域内做字节重排，操作后会被恢复。但第三步直接把4字节写到了dst[assoclen + cryptlen] 的位置——这个位置已经超出了AEAD解密输出的合法边界（合法输出只有AAD || plaintext，长度是assoclen+(cryptlen-authsize)）。
内核中所有其他标准 AEAD 算法（GCM、CCM、普通 authenc）都严格限制写入在合法输出区域内，只有 authencesn 会越界写这 4 个字节。
在正常的out-of-place操作中，这个越界写只会踩到调用者分配的RX缓冲区的后续内存，通常无害。但在这个in-place+splice的组合路径下：
req->src == req->dst，dst就是RX SGL
RX SGL的尾部通过sg_chain()链引用了/usr/bin/su的页缓存页面
scatterwalk_map_and_copy会沿着scatterlist walk到这些页缓存页面，通过kmap_local_page() 建立临时映射
然后直接写入
结果是：内核加密算法“帮”攻击者向任意可读文件的页缓存写了4个字节。
攻击者对这次写入拥有三重精确控制：
由于recvmsg()触发解密后，HMAC校验必然失败（因为密文是伪造的），内核会返回-EBADMSG错误，但scratch write发生在HMAC校验之前，所以错误码不影响污染结果。
攻击者只需重复这个过程多次（每次改4字节，多次覆盖不同偏移），就能在/usr/bin/su的.text段里拼出完整的shellcode。然后执行被污染的su，内核从页缓存加载二进制，setuid-root+被篡改的代码=root shell。
完整攻击流程可以概括为五步：
Step 1— Socket 初始化
sock = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0)sock.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))
无需任何特权。AF_ALG在绝大多数发行版上对普通用户默认开放。
Step 2— 加载密钥并创建会话套接字通过setsockopt设置AEAD密钥，然后accept()得到操作套接字opsock。
Step 3— 构造write-4原语对于目标文件（默认 /usr/bin/su）中的每一个需要修改的4字节位置：
计算对应的splice偏移和AEAD参数
sendmsg()发送AAD，其中bytes 4-7为要写入的payload chunk
splice(target_fd, pipe) 把目标文件的页缓存页面送进内核
splice(pipe, opsock) 把页面引用送入AF_ALG输入
opsock.recv(...) # 触发解密 → authencesn scratch write → 页缓存污染 → 返回 EBADMSG
写入在recv()进入内核时完成。虽然用户态收到错误，但页缓存已被篡改。
Step 5 — 执行被污染的二进制
execve("/usr/bin/su", ...)
内核加载器从页缓存读取su的代码段，执行的是攻击者注入的shellcode，且因为su是setuid-root，shellcode以UID 0运行。
整个过程不需要内核地址泄露、不需要ROP、不需要竞争窗口、不需要编译任何C代码。732字节的纯Python标准库脚本，跨发行版、跨架构通用。
Copy Fail的可怕不仅在于提权本身，还在于它的反取证特性。
写入的是页缓存（page cache），内核不会把这些页面标记为dirty，因此不会触发writeback 回写磁盘。磁盘上的原始文件校验和（sha256、rpm -Va、debsums）完全不变。
页缓存级别的写入不经过VFS的常规write路径，因此文件监控工具看不到"write"事件。
页缓存是非持久的，重启后磁盘上的原始文件会被重新读入内存，篡改消失。但攻击者获得的root shell是真实的，可以在此期间植入持久化后门。
在容器/Kubernetes环境中，宿主机的页缓存是全局共享的。一个容器内的普通用户，可以通过这个漏洞污染宿主机上/usr/bin/su的页缓存，实现从Pod到Host的容器逃逸。
这意味着什么？ 你的EDR、文件完整性监控（FIM）、审计日志，都可能对这个利用过程“视而不见”。传统的“检测磁盘文件是否被篡改”的思路在这里彻底失效。
验证数据来源：微步情报局实测（见参考链接）。由于漏洞源于内核4.14+的crypto子系统，凡是基于Linux Kernel4.14及以上版本的信创与商业发行版，均建议默认按「受影响」处置，直至完成内核补丁升级或缓解措施落地。
如果无法立即升级内核，最快的缓解措施是禁用algif_aead内核模块：
# 写入 modprobe 黑名单echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf# 如果模块已加载，立即卸载rmmod algif_aead 2>/dev/null || true
绝大多数系统不会感知到功能缺失。以下组件不受影响。
dm-crypt / LUKS（直接调用内核 crypto API，不走AF_ALG）
kTLS、IPsec/XFRM、in-kernel TLS
OpenSSL/GnuTLS/NSS默认构建（不启用 afalg引擎时）
SSH、kernel keyring crypto
可用lsof|grep AF_ALG或ss -xa检查当前是否有进程使用AF_ALG。
对于运行不可信工作负载的容器、沙箱、CI环境，无论内核是否已补丁，都建议用seccomp或LSM阻断 socket(AF_ALG, ...) 的创建。
{ "names": ["socket"], "action": "SCMP_ACT_ERRNO", "args": [ { "index": 0, "value": 38, "op": "SCMP_CMP_EQ", "valueTwo": 0 } ]}
（38是AF_ALG的协议族编号）
官方修复思路非常直接——把2017年的in-place优化全部回退，恢复out-of-place操作。
commit a664bf3d603dAuthor: Herbert Xucrypto: algif_aead - Revert to operating out-of-placeThis mostly reverts commit 72548b093ee3 except for the copying ofthe associated data.There is no benefit in operating in-place in algif_aead since thesource and destination come from different mappings. Get rid ofall the complexity added for in-place operation and just copy theAD directly.
修复后，req->src和req->dst重新分离，页缓存页面只留在只读的source scatterlist中，不可能被算法写入。
由于利用过程不修改磁盘，传统 FIM 无法检测，建议进行以下操作。
🔷 监控异常AF_ALG使用：审计普通用户进程对AF_ALG套接字的创建和大量splice+recvmsg失败（EBADMSG）的组合；
🔷 内存级完整性校验：对关键setuid二进制（/usr/bin/su、/usr/bin/sudo、/usr/bin/passwd）做运行时内存哈希（从/proc/kpageflags或内核模块角度监控页缓存内容异常）；
🔷 行为检测：观察非特权用户突然执行su并获取root shell的异常行为链；
🔷 日志审查：检查/var/log/auth.log、/var/log/secure 中异常的su/sudo提权成功记录，尤其是从低价值账户发起的提权。
Copy Fail是一个教科书级别的案例：一个没有实际收益的性能优化（in-place AEAD），加上一个为省事而越界写缓冲区的算法实现（authencesn scratch write），再叠加上splice的零拷贝页缓存引用机制，最终构成了一个9年未被发现的完美提权漏洞。
‼ 它提醒我们几件事
🔷 内核中的“小优化”有时是安全性的敌人。当source和dst本就来自不同映射时，in-place操作不仅没省多少，反而破坏了缓冲区边界的清晰性。
🔷 Scatterlist的页面来源审计是内核安全中一个长期被忽视的盲区。来自文件页缓存的页面和来自用户态私有缓冲区的页面，在同一条scatterlist中拥有完全不同的安全语义。
🔷 页缓存污染是一种极其隐蔽的攻击原语。它绕过了磁盘层面的所有完整性校验和监控，却在内存中实现了对系统关键文件的持久化篡改（直到页被回收）。
🔷 AI辅助代码审计正在改变漏洞发现的格局。这个漏洞由Theori的Taeyang Lee提出攻击面假设，通过Xint Code在约1小时内完成对Linux crypto子系统的全面扫描后定位，预示着未来这类跨机制组合的“逻辑型漏洞”将被更频繁地发现。
麒麟实验室建议：所有运行2017年以后内核的Linux 服务器，无论是否直接暴露于不可信用户环境，都应视此漏洞为“必修项”。在多租户、容器化、CI/CD场景中，其风险等级不亚于Dirty Pipe和Dirty Cow。
官方披露与PoC：https://copy.fail/
GitHub仓库：https://github.com/theori-io/copy-fail-CVE-2026-31431
Xint Code技术分析：https://xint.io/blog/copy-fail-linux-distributions
Linux官方补丁：https://git.kernel.org/stable/c/a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5
NVD条目：https://nvd.nist.gov/vuln/detail/CVE-2026-31431
OSS-Security公告：https://www.openwall.com/lists/oss-security/2026/04/29/23
麒麟实验室持续关注内核安全、攻防技术与漏洞研究。本文仅供安全技术交流，请合法合规使用相关信息。
10个月宝宝每天需要喝多少奶粉？
