概述

近期，安全研究人员公开披露了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-2026-31431

• 漏洞名称：Copy Fail

• 漏洞类型：Linux Kernel本地权限提升/容器逃逸原语

• 触发条件：攻击者已获得本地普通用户或容器内代码执行权限

• 是否需要网络访问：不需要

• 是否需要竞争条件：研究方称不需要race window

• 是否已有公开PoC：是，研究方已公开验证PoC

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

风险评估

       (一)高风险场景

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

      （二）中风险场景

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

（三）较低风险场景

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

影响范围

（一）受影响系统

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

（二）受影响模块

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

（三）受影响环境

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

（四）高风险场景

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

（五）已验证受影响的系统

    （1）Ubuntu 24.04 LTS、Amazon Linux 2023、RHEL、SUSE 等多个发行版与内核组合；

    （2） Debian、Arch、Fedora、Rocky、Alma、Oracle Linux 以及嵌入式系统等如果运行受影响内核，也可能处于风险范围。

漏洞原理

根据公开的技术分析，该漏洞的核心原理可概括为：

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

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

排查方法

（一）查看当前内核版本

uname -a

uname -r

（二）检查 algif_aead 模块是否已加载

lsmod | grep '^algif_aead'

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

（三）检查是否已配置禁用模块

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

（四）检查系统中是否存在 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 的程序可能受影响。

解决方案

（一）首选方案：更新内核

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

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

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

 # 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

（2）升级后请使用uname -r确认运行内核版本。

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

（二）临时缓解方案

在无法立即升级内核的情况下，可采取以下临时缓解措施：

1. 禁用algif_aead模块

（1）执行以下命令：

echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf

sudo rmmod algif_aead 2>/dev/null || true

（2）验证是否生效

lsmod | grep '^algif_aead'     #如果无输出，说明当前模块未加载。

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

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

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

        处置原则：禁止非可信容器 / 构建任务 / 沙箱任务创建 AF_ALG socket

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

应急响应措施

(一)立即冻结高风险环境

（1）暂停高风险CI Runner

（2）暂停共享沙箱任务

（3）暂停多租户Notebook/容器任务

(二)全量盘点Linux内核版本

（1）Kubernetes 节点

（2）CI/CD 节点

（3）跳板机

（4）开发机

（5）云主机

（6）边缘节点

（7）嵌入式 Linux 设备

(三)先做临时缓解

（1）禁用 algif_aead

（2）容器环境阻断 AF_ALG

(四)尽快升级内核并重启

（1）使用发行版官方安全更新

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

(五)对高风险节点做事后排查

在完成上述缓解或修复后，应对曾暴露在高风险下的节点（CI Runner、容器宿主机、多用户服务器、有公网 RCE 风险的业务主机）进行入侵痕迹检查，以确认是否已被利用。

1. 重点排查对象

排查 CI Runner、构建机、容器节点是否存在以下现象：

（1）是否运行过不可信PR

（2）是否执行过外部脚本

（3）是否存在异常root shell

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

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

last

lastlog

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

grep -i "session opened" /var/log/secure 2>/dev/null

 3. 检查 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

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

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

(六)恢复服务与持续监控

在确认漏洞已修复且未发现成功入侵后，逐步恢复第一阶段冻结的服务。加强相关节点的日志监控与审计，重点关注权限提升行为。

注：本通告基于公开披露的技术分析整理，具体修复方案请参考各操作系统厂商的官方安全公告。