Linux 内核 Copy Fail 本地提权漏洞(CVE-2026-31431)

漏洞级别：高危 / 紧急修复
漏洞名称：Copy Fail
漏洞编号：CVE-2026-31431
影响类型：本地权限提升、容器逃逸、共享主机越权、CI Runner 节点接管
披露时间：2026 年 4 月 29 日公开披露

一、漏洞概述

近期，Theori / Xint Code 公开披露 Linux 内核漏洞 Copy Fail（CVE-2026-31431）。该漏洞存在于 Linux 内核加密子系统相关逻辑中，攻击者在获得本地普通用户权限后，可通过 AF_ALG、splice() 与 authencesn 相关逻辑组合，触发对 page cache 的受控写入，从而实现本地提权。研究方称，公开 PoC 可在多个主流 Linux 发行版上将普通用户提升为 root。

该漏洞的危险点不在于远程直接入侵，而在于它会把“已经获得的低权限执行点”迅速放大为 root 权限。因此，对于多用户 Linux 主机、Kubernetes 节点、容器平台、CI/CD 构建机、自托管 Runner、云端 Notebook、沙箱执行环境等场景，风险显著高于普通单用户服务器。研究方特别指出，page cache 在宿主机范围内共享，因此该问题也具备容器逃逸和跨租户影响。



二、漏洞基本信息

项目 内容

CVE 编号 CVE-2026-31431
漏洞名称 Copy Fail
漏洞类型 Linux Kernel 本地权限提升 / 容器逃逸原语
触发条件 攻击者已获得本地普通用户或容器内代码执行权限
是否需要网络访问 不需要
是否需要竞争条件 研究方称不需要 race window
是否已有公开 PoC 是，研究方已公开验证 PoC
修复方式 更新包含内核修复提交 a664bf3d603d 的发行版内核
临时缓解 禁用 algif_aead 模块，或在容器/沙箱中阻断 AF_ALG socket 创建


Linux 主线修复提交为 a664bf3d603d，提交说明显示该修复将 algif_aead 回退到 out-of-place 操作，移除此前 in-place 处理带来的复杂逻辑；该提交标记修复了 2017 年引入的相关变更。



三、影响范围

根据公开披露信息，漏洞影响范围主要包括：

1. 2017 年以来构建、且尚未包含修复提交的 Linux 内核


2. 默认启用或可加载 algif_aead 模块的 Linux 系统


3. 允许非特权用户创建 AF_ALG socket 的环境


4. 运行多租户任务、容器任务、CI 任务、沙箱任务的共享内核环境



研究方已直接验证的系统包括 Ubuntu 24.04 LTS、Amazon Linux 2023、RHEL、SUSE 等多个发行版与内核组合；同时说明 Debian、Arch、Fedora、Rocky、Alma、Oracle Linux 以及嵌入式系统等如果运行受影响内核，也可能处于风险范围。

需要注意的是，不同厂商对该漏洞的评分可能不完全一致。例如 Ubuntu 安全页面将其优先级标为 High，CVSS 3 分数为 7.8；Amazon Linux 页面显示为 Medium，CVSS 3 基础分为 5.5。评分差异不应影响运维优先级判断：在多租户、容器、CI、沙箱环境中，应按高危漏洞处理。



四、漏洞原理简述

Copy Fail 的核心问题可以概括为一句话：

Linux 内核在 AF_ALG AEAD 加密接口中将来自 page cache 的数据页错误地放入可写 scatterlist，随后 authencesn 逻辑中的越界 scratch write 可对 page cache 中的文件内容产生受控 4 字节写入。



公开技术分析显示，攻击者可通过 splice() 将目标文件的 page cache 页引用传入内核 crypto 路径，再通过 authencesn 的处理逻辑触发越界写入。由于写入发生在 page cache 中，而不是直接写入磁盘文件，因此磁盘上的文件内容可能保持不变，普通基于磁盘校验和的完整性检查可能无法发现该修改。

这也是该漏洞危险性较高的原因之一：攻击者可以影响系统实际执行时读取到的内存缓存内容，而传统“文件落盘是否被篡改”的检查不一定能覆盖这种场景。



五、风险评估

1. 高风险场景

以下环境应立即排查并优先修复：

场景 风险说明

Kubernetes / 容器平台 容器内低权限代码可能提升为宿主机 root
自托管 CI Runner 恶意 PR、构建脚本、依赖投毒可转化为 Runner 节点接管
多用户 Linux 主机 任意普通用户可能提权为 root
云端 Notebook / 代码沙箱 租户代码可突破隔离边界
PaaS / Serverless 执行环境 用户提交代码可能影响宿主节点
堡垒机 / 跳板机 / 开发机 普通账号失陷后可扩大为系统完全控制


2. 中风险场景

单租户生产服务器如果没有普通用户登录入口，直接风险相对较低。但一旦 Web 服务、业务进程、运维账号、SSH 凭据、计划任务、插件系统、上传执行点被攻击者利用，该漏洞就可能成为后续提权工具。

3. 较低风险场景

单用户桌面、个人开发机的风险取决于是否运行不可信代码。它不是远程漏洞，但恶意脚本、恶意软件、供应链投毒包一旦获得本地执行机会，可能利用该漏洞提升权限。



六、排查方法

1. 查看当前内核版本

uname -a
uname -r

2. 检查 algif_aead 模块是否已加载

lsmod | grep '^algif_aead'

有输出说明模块当前已加载；无输出不代表一定安全，因为模块可能在后续被自动加载。

3. 检查是否已配置禁用模块

cat /etc/modprobe.d/disable-algif.conf 2>/dev/null
cat /etc/modprobe.d/disable-algif-aead.conf 2>/dev/null

应看到类似内容：

install algif_aead /bin/false

4. 检查系统中是否存在 AF_ALG 使用行为

lsof | grep AF_ALG
ss -xa | grep -i alg

研究方说明，禁用 AF_ALG 通常不会影响 dm-crypt/LUKS、kTLS、IPsec/XFRM、OpenSSL/GnuTLS/NSS 默认构建、SSH、kernel keyring crypto 等常见能力；但显式使用 AF_ALG 的用户态加密加速、嵌入式 crypto offload 或直接绑定 aead/skcipher/hash socket 的程序可能受影响。



七、修复建议

1. 首选方案：更新内核

应立即通过发行版官方渠道升级 Linux kernel，确保新内核包含主线修复提交：

a664bf3d603d

研究方与 Linux 主线提交均显示，该修复通过回退 algif_aead 的 in-place 操作逻辑，避免 page cache 页进入可写目标 scatterlist。

常见发行版可参考如下操作：

# Debian / Ubuntu
sudo apt update
sudo apt full-upgrade
sudo reboot

# RHEL / Rocky / Alma / Oracle Linux / Fedora
sudo dnf update kernel
sudo reboot

# Amazon Linux 2023
sudo dnf update kernel
sudo reboot

# SUSE / openSUSE
sudo zypper refresh
sudo zypper patch
sudo reboot

升级后再次确认运行内核版本：

uname -r

注意：仅安装新内核包还不够，必须重启进入新内核。



2. 临时缓解方案：禁用 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

验证：

lsmod | grep '^algif_aead'

如果无输出，说明当前模块未加载。

该缓解措施来自研究方公开建议，用于在正式打补丁前降低攻击面。



3. 容器与沙箱环境：阻断 AF_ALG

对于 Kubernetes、容器平台、CI Runner、代码沙箱、Notebook 等运行不可信代码的环境，即使已计划升级内核，也建议通过 seccomp 或运行时安全策略阻断容器内创建 AF_ALG socket。

处置原则：

禁止非可信容器 / 构建任务 / 沙箱任务创建 AF_ALG socket

这类环境的风险不只是普通本地提权，而是可能演变为容器逃逸、宿主机接管、跨租户攻击。研究方也明确建议在不可信 workload 中通过 seccomp 阻断 AF_ALG socket 创建。



八、检测与应急建议

由于该漏洞利用可能只修改 page cache，磁盘文件不一定发生变化，单纯依赖文件 hash 校验并不可靠。建议从以下方向进行应急排查：

1. 排查近期是否有普通用户异常获得 root 权限

last
lastlog
grep -i "session opened" /var/log/auth.log 2>/dev/null
grep -i "session opened" /var/log/secure 2>/dev/null


2. 检查 sudo、su、setuid 程序的异常执行

grep -i "su:" /var/log/auth.log 2>/dev/null
grep -i "sudo" /var/log/auth.log 2>/dev/null
grep -i "sudo" /var/log/secure 2>/dev/null


3. 重点排查 CI Runner、构建机、容器节点

是否运行过不可信 PR

是否执行过外部脚本

是否存在异常 root shell

是否有未知用户、未知 SSH key、未知 cron 任务



4. 发现疑似利用后建议重启

该漏洞影响 page cache，研究方说明其对文件磁盘内容的修改并非持久化；但成功提权后攻击者可能已经写入持久化后门。因此重启只能清除 page cache 层面的影响，不能替代完整入侵排查。






九、优先处置清单

建议按以下顺序推进：

1. 立即冻结不可信代码执行环境

暂停高风险 CI Runner

暂停共享沙箱任务

暂停多租户 Notebook / 容器任务



2. 全量盘点 Linux 内核版本

Kubernetes 节点

CI/CD 节点

跳板机

开发机

云主机

边缘节点

嵌入式 Linux 设备



3. 先做临时缓解

禁用 algif_aead

容器环境阻断 AF_ALG



4. 尽快升级内核并重启

使用发行版官方安全更新

确认运行中的内核已切换到修复版本



5. 对高风险节点做事后排查

CI Runner

容器宿主机

多用户服务器

有公网 RCE 风险的业务主机






十、安全建议结论

CVE-2026-31431 不是远程直接打穿型漏洞，但它是非常危险的本地提权与容器逃逸型漏洞。在现代基础设施中，本地执行点并不罕见：Web RCE、弱口令 SSH、CI 构建脚本、恶意依赖包、容器逃逸链、Notebook 代码执行都可能成为前置条件。

因此，本漏洞应按以下原则处置：

单用户服务器：尽快修复。
多用户主机、容器节点、CI Runner、沙箱平台：立即修复。
暂时无法修复的系统：立即禁用 algif_aead 并限制 AF_ALG。



不要在生产环境运行公开 PoC。PoC 会影响 setuid 程序的 page cache，虽然磁盘文件不一定被持久修改，但获得的 root shell 是真实有效的。研究方也明确建议 PoC 仅用于授权测试和补丁验证。