Linux又现高危漏洞!!!速修(含修复方式)

一、漏洞概述

近日，Linux Kernel 披露本地提权漏洞 CVE-2026-31431，该漏洞也被研究人员命名为 Copy Fail。

漏洞位于 Linux 内核加密子系统，核心涉及：

• AF_ALG
  ：Linux 暴露给用户态的内核加密接口
• algif_aead
  ：AEAD 加密算法 socket 接口
• authencesn
  ：IPsec ESN 场景下使用的 AEAD 包装算法
• splice()
  ：零拷贝数据传输机制
• Page Cache：Linux 文件页缓存

攻击者在获得普通本地用户权限后，可利用该漏洞构造 对任意可读文件 Page Cache 的 4 字节可控写入。在公开研究中，该能力被用于修改内存中的 setuid 程序页面，从而实现 root 权限提升。

该漏洞不是远程漏洞，但在以下场景风险较高：

• 多用户 Linux 主机
• 跳板机、堡垒机、共享开发机
• CI/CD Runner、构建服务器
• Kubernetes / 容器集群节点
• Web RCE 后的二阶段提权

二、漏洞技术细节

1. AF_ALG 与 splice 的组合风险

AF_ALG 允许用户态程序通过 socket 调用内核加密 API。普通用户通常也可以创建该类型 socket。

splice() 则可以在文件描述符之间移动数据，避免用户态复制。当攻击者将某个可读文件通过 splice() 送入 AF_ALG crypto socket 时，内核 scatterlist 中可能引用的是该文件的 Page Cache 页面。

也就是说，攻击者并不是把文件内容复制了一份，而是让 crypto 路径“看见”了文件缓存页。

2. algif_aead 的 in-place 设计缺陷

问题的关键来自 2017 年引入的一个优化：algif_aead 在 AEAD 解密路径中使用了 in-place operation。

简化理解：

正常预期：src = 输入数据dst = 用户接收缓冲区危险设计：src 和 dst 指向同一组 scatterlist部分 tag 数据仍然引用 Page Cache 页面

在该路径中，AEAD 的 tag 区域可能通过 sg_chain() 被连接到输出 scatterlist 后面，而这些 tag 页面仍然可能是由 splice() 引入的文件 Page Cache 页面。

这会造成一个危险结果：

原本只应被读取的文件缓存页，被放入了“可写”的目标 scatterlist 中。

3. authencesn 的越界 scratch write

authencesn 在处理 ESN 相关数据时，会使用目标 scatterlist 作为临时 scratch 空间。

公开分析显示，其解密流程中会在 dst[assoclen + cryptlen] 附近写入 4 字节数据。正常情况下，这只是算法内部临时操作；但在 CVE-2026-31431 的组合场景下，这 4 字节会落到被链入的 Page Cache 页面上。

最终形成：

低权限用户  |  | AF_ALG + AEAD + authencesn  |  | splice() 引入文件 Page Cache  |  | algif_aead in-place 处理  |  | authencesn 写入 scratch 数据  v可控 4 字节写入 Page Cache

三、影响范围

根据公开资料，该问题由 Linux Kernel commit 72548b093ee3 引入，修复方式是回退 algif_aead 的 in-place 处理逻辑。

公开信息中提到的修复版本包括：

Debian 安全跟踪页面显示，截至 2026-04-30，部分 Debian 稳定发行分支仍标记为 vulnerable，sid / forky 已显示 fixed。实际生产环境请以各发行版安全公告为准。

高风险资产包括：

• 允许普通用户登录的 Linux 主机
• 运行不可信代码的 CI Runner
• 多租户容器平台
• 暴露 Web 服务且存在 RCE 风险的服务器
• 使用自维护内核或较慢打补丁的云镜像

四、PoC / Payload 说明

公开研究团队已经发布 PoC，宣称可在多个主流发行版上完成本地提权测试。公开 PoC 的典型思路是：

1. 创建 AF_ALG AEAD socket2. 绑定 authencesn(hmac(sha256),cbc(aes))3. 使用 splice() 将目标 setuid 文件页面送入 crypto 路径4. 构造 AAD，使 4 字节可控值落入目标 Page Cache 偏移5. 多次触发，修改内存中的 setuid 程序页面6. 执行被污染的 setuid 程序，获得 root

#!/usr/bin/env bashecho "[*] CVE-2026-31431 safe exposure check"echo "[+] Kernel:"uname -recho "[+] AF_ALG / crypto user API:"grep -E "CONFIG_CRYPTO_USER_API|CONFIG_CRYPTO_USER_API_AEAD" /boot/config-$(uname -r) 2>/dev/null \  || zgrep -E "CONFIG_CRYPTO_USER_API|CONFIG_CRYPTO_USER_API_AEAD" /proc/config.gz 2>/dev/null \  || echo "Cannot read kernel config"echo "[+] algif_aead module:"lsmod | grep algif_aead || echo "algif_aead not loaded or built-in"echo "[+] SUID binaries:"find /usr/bin /bin /usr/sbin /sbin -perm -4000 -type f 2>/dev/nullechoecho "[!] This script does not exploit the vulnerability."echo "[!] If kernel is in vulnerable range and AEAD user API is available, upgrade immediately."

安全自查命令

可在资产侧先做基础排查：

uname -a

检查当前内核版本是否低于发行版公告中的修复版本。

检查 algif_aead 模块状态：

lsmod | grep algif_aeadmodinfo algif_aead 2>/dev/null

检查系统是否支持 AF_ALG：

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

检查 setuid 程序面：

find / -perm -4000 -type f 2>/dev/null

五、修复建议

1. 优先升级内核

最推荐的修复方式是升级到发行版提供的安全内核版本。

Debian / Ubuntu：

sudo apt updatesudo apt full-upgradesudo reboot

sudo dnf update kernelsudo reboot

sudo dnf update kernelsudo reboot

uname -r

 容器与 CI 场景加固

对 Kubernetes、CI Runner、沙箱类业务，建议同步采取：

• 避免在共享内核上运行不可信代码
• 对容器启用严格 seccomp profile
• 限制容器内创建 AF_ALG socket 的能力
• 对自托管 CI Runner 做任务隔离，避免多租户复用同一节点
• 优先重建基础镜像与宿主机内核

六、总结

CVE-2026-31431 的危险点不在于远程打点，而在于它把“普通本地用户”到“root”的距离压得非常短。

它本质上是多个内核机制叠加后的边界失守：