CVE-2026-31431 Copy Fail：732字节Python脚本攻破Linux内核，容器逃逸零门槛
2026年5月1日，安全研究团队Xint披露了Linux内核加密子系统中的一个提权漏洞（CVE-2026-31431，代号Copy Fail）。这个漏洞仅需732字节的Python脚本即可实现从普通用户到root的提权，且同一份exploit代码无需修改即可在Ubuntu、RHEL、Amazon Linux、SUSE等所有主流发行版上运行。更严重的是，该漏洞可穿越容器边界，实现容器到宿主机的逃逸。
漏洞概述：Copy Fail是什么
CVE-2026-31431是Linux内核crypto API中AF_ALG子系统的一个逻辑漏洞，存在于authencesn加密模板的in-place优化路径中。该漏洞允许任何无特权的本地用户对任意可读文件的页面缓存（page cache）写入4字节数据。这4字节足以劫持一个setuid二进制文件或被特权进程执行的程序，从而获得root权限。
该漏洞自2017年引入（当时内核添加了AEAD加密路径的in-place优化），直到2026年5月才被发现，潜伏了将近9年。这意味着从2017年到补丁发布期间的所有Linux发行版——包括Ubuntu、Debian、RHEL、Fedora、SUSE、Amazon Linux、Arch、Rocky、Alma等——全部受到影响。
| 属性 | 值 |
|---|---|
| CVE编号 | CVE-2026-31431 |
| 代号 | Copy Fail |
| 漏洞类型 | 本地提权（LPE）+ 容器逃逸 |
| 影响子系统 | Linux kernel crypto API, AF_ALG |
| 发现者 | Xint |
| 披露日期 | 2026-05-01 |
| 修复提交 | mainline commit a664bf3d603d |
| 影响范围 | 2017年至补丁发布期间的所有主流Linux发行版 |
| PoC大小 | 732字节 Python脚本 |
技术原理：4字节写入如何变成root
Copy Fail的核心是AF_ALG（用户态加密API）中的一个逻辑缺陷。整个利用链由三个关键技术组成：
AF_ALG socket： Linux内核提供的用户态加密接口，任何进程无需root权限或特殊capability即可使用。通过socket(AF_ALG, SOCK_SEQPACKET, 0)创建。
splice()系统调用： 允许在文件描述符和管道之间移动数据，无需经过用户态拷贝。利用splice可以将目标文件（如setuid二进制）的页面直接送入内核的加密操作中。
Page Cache共享： 这是利用链的关键。内核的页面缓存是全局共享的——同一宿主机上的所有容器、宿主机本身、kube-proxy等特权组件，只要读取同一个文件（比如基础镜像层中的二进制），都会从同一组物理页面中读取。
# 漏洞利用核心流程（简化）
import os, socket, zlib
# Step 1: 创建AF_ALG socket
s = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0)
s.bind(('aead', 'authencesn(hmac(sha256),cbc(aes))'))
# Step 2: splice目标文件页面到加密操作
target = os.open('/usr/bin/su', os.O_RDONLY)
os.splice(target, pipe_write, 4096)
os.splice(pipe_read, alg_fd, 4096)
# Step 3: 内核in-place优化将加密结果写回同一页面
# 4字节被覆盖到目标文件的页面缓存中
# 执行被篡改的setuid二进制 → 获得root
为什么4字节就够了？ 在ELF二进制文件中，4字节足以插入一个近跳转指令或重定向函数指针。exploit选择一个偏移量，将目标二进制改写为攻击者payload的小型加载器。
容器逃逸：从Pod到Node的完整路径
Copy Fail对容器化环境的威胁尤为严重。因为页面缓存跨容器共享，攻击路径如下：
Kubernetes PoC路径： 攻击者在一个无特权的Pod中运行exploit，目标是/usr/sbin/ipset（kube-proxy以root身份调用的二进制）。当DaemonSet中的kube-proxy执行被篡改的ipset时，攻击者获得节点上的root执行权限。
[无特权Pod] → splice /usr/sbin/ipset → 4字节覆盖 →
等待kube-proxy执行 → 获得Node root权限 →
横向移动到其他节点/命名空间
关键点：标准的Kubernetes seccomp profile对AF_ALG socket没有限制。runtime/default seccomp配置允许socket()系统调用创建AF_ALG类型的socket，因此默认安全配置无法阻止该利用。
| 场景 | 风险等级 | 说明 |
|---|---|---|
| 多租户Linux主机 | 🔴 高 | 共享开发机、shell服务、跳板机——任何用户可提权 |
| Kubernetes/容器集群 | 🔴 高 | 页面缓存跨容器共享，Pod可逃逸到Node |
| CI运行器/构建农场 | 🔴 高 | GitHub Actions self-hosted runner执行不受信PR代码 |
| 运行用户代码的云SaaS | 🟡 中 | Notebook宿主机、Agent沙箱、Serverless函数 |
| 单租户服务器 | 🟢 低 | 仅内部提权，需结合Web RCE或窃取的凭证 |
受影响系统全面盘点
Xint团队直接验证了以下发行版，其他未列出的发行版（Debian、Fedora、Arch、Rocky、Alma、Oracle、嵌入式系统）在未打补丁的内核上同样受影响：
| 发行版 | 验证内核版本 | 状态 |
|---|---|---|
| Ubuntu 24.04 LTS | 6.17.0-1007-aws | ✅ 已验证 |
| Amazon Linux 2023 | 6.18.8-9.213.amzn2023 | ✅ 已验证 |
| RHEL 10.1 | 6.12.0-124.45.1.el10_1 | ✅ 已验证 |
| SUSE 16 | 6.12.0-160000.9-default | ✅ 已验证 |
不受影响的组件： dm-crypt/LUKS、kTLS、IPsec/XFRM、内核TLS、OpenSSL/GnuTLS/NSS默认构建、SSH、内核密钥环加密——这些组件直接使用内核加密API，不经过AF_ALG。
检测与验证
检查系统是否受影响
# 方法1：检查algif_aead模块是否可加载
lsmod | grep algif_aead
# 如果有输出，说明模块已加载，系统受影响
# 方法2：使用官方验证脚本
curl -sO https://copy.fail/verify.sh && bash verify.sh
# 该脚本不会提权，仅检测内核是否存在漏洞路径
# 方法3：检查内核版本
uname -r
# 2017年以后的内核版本默认受影响
检查是否已被利用
# 检查setuid二进制的完整性
dpkg --verify 2>/dev/null | grep "^.5"
rpm -Va 2>/dev/null | grep "^.5"
# 检查页面缓存中是否有异常修改
# （需要重启后对比，因为页面缓存修改不持久化到磁盘）
修复方案
方案一：更新内核（推荐）
# Ubuntu/Debian
sudo apt update && sudo apt upgrade -y linux-image-$(uname -r)
sudo reboot
# RHEL/CentOS
sudo yum update kernel -y
sudo reboot
# Amazon Linux
sudo yum update kernel -y
sudo reboot
# SUSE
sudo zypper update kernel-default
sudo reboot
方案二：临时缓解——禁用AF_ALG模块
如果无法立即重启，可以禁用受影响的内核模块：
# 写入模块黑名单
echo "install algif_aead /bin/false" | \
sudo tee /etc/modprobe.d/disable-algif.conf
# 卸载已加载的模块
sudo rmmod algif_aead 2>/dev/null
# 验证
lsmod | grep algif_aead
# 无输出 = 已禁用
禁用AF_ALG的影响： 对绝大多数系统没有可感知的影响。dm-crypt/LUKS、kTLS、IPsec、OpenSSL默认构建、SSH等都不依赖AF_ALG。仅当用户态程序显式使用AF_ALG引擎（如OpenSSL的afalg engine）时才会受影响。
方案三：容器环境额外措施
# Kubernetes Pod Security Policy / SecurityContext
securityContext:
seccompProfile:
type: RuntimeDefault
# 注意：RuntimeDefault可能不足以阻止AF_ALG
# 需要自定义seccomp profile阻止socket(AF_ALG)
# 自定义seccomp profile阻止AF_ALG
# 在seccomp profile中添加：
{
"syscalls": [
{
"names": ["socket"],
"action": "SCMP_ACT_ERRNO",
"args": [
{"index": 0, "value": 38, "op": "SCMP_CMP_EQ"}
]
}
]
}
历史对比：近年Linux内核提权漏洞
| CVE | 代号 | 类型 | 利用难度 | 容器逃逸 |
|---|---|---|---|---|
| CVE-2026-31431 | Copy Fail | 逻辑漏洞 | 极低（直行代码） | ✅ |
| CVE-2024-1086 | — | nf_tables UAF | 中（需竞态） | ✅ |
| CVE-2023-32233 | — | nf_tables UAF | 中 | ✅ |
| CVE-2022-0847 | Dirty Pipe | 逻辑漏洞 | 低 | 部分 |
| CVE-2021-4034 | PwnKit | pkexec逻辑 | 低 | 否 |
Copy Fail的利用难度与Dirty Pipe类似，但影响范围更广——它不需要目标文件具有特定权限（Dirty Pipe需要可写文件描述符），且同一份exploit在所有发行版上通用。
数据来源与参考文献
- Copy Fail 官方网站. "CVE-2026-31431." copy.fail, 2026.
- Xint. "Copy Fail Write-up." GitHub: theori-io/copy-fail-CVE-2026-31431, 2026.
- Ubuntu Blog. "Fixes available for CVE-2026-31431 (Copy Fail)." ubuntu.com, 2026.
- Laravel Forge. "Copy Fail security advisory (CVE-2026-31431)." forge.laravel.com, 2026.
- DevOps Daily. "CVE-2026-31431 Copy Fail: A 4-Byte Kernel Write That Escapes Containers." devops-daily.com, 2026.
更新时间: 2026-06-28
评论