CVE-2026-31431 Copy Fail：Linux 本地提权漏洞原理、影响面与排查修复建议

CVE-2026-31431 / Copy Fail 不是远程 RCE，攻击者需要先在目标机器上具备低权限代码执行能力。但这并不意味着它只是一个“小本地洞”。在容器节点、CI runner、共享开发机、跳板机、代码沙箱、Notebook、AI Agent 执行机这类环境里，“低权限代码执行”本来就经常存在。一旦这类入口和内核本地提权连起来，风险就可能从普通用户权限扩大到宿主机、节点或构建环境。

Copy Fail 的核心问题在 Linux kernel crypto 子系统。公开资料显示，algif_aead / authencesn 相关路径在处理 AF_ALG 和 splice() 组合时，可能把一次本应失败的加密操作，变成对文件 page cache 的可控写入。这个点很关键：攻击者不一定直接改磁盘文件，但进程实际执行时可能读到已经被污染的页缓存。

本文只做防守分析和排查建议，不提供可复制利用步骤。

漏洞基本信息

这里有一个排查上的细节：不要只看主线内核版本号。很多发行版会 backport 修复，内核版本字符串看起来没有变化，但补丁已经合入；也可能版本看起来接近安全线，但发行版还没发布对应修复包。最终应以发行版安全公告、补丁包和实际运行内核为准。

为什么本地提权也要重视

很多人看到“本地提权”会先松一口气，因为它不像远程 RCE 那样可以直接从公网打进来。

但现在的基础设施里，本地执行入口并不少见：

• CI/CD 会执行外部 PR、构建脚本、依赖安装脚本。
• Kubernetes 节点会运行多个容器和任务。
• 共享开发机、跳板机、运维工具机可能有多个用户。
• Notebook、代码沙箱、在线实验环境本来就允许用户跑代码。
• AI Agent 执行机可能会帮用户运行命令、拉仓库、装依赖、跑测试。

在这些场景里，攻击者不一定一开始就是 root。他只要拿到普通代码执行，就可能借本地提权漏洞继续向上走。所以判断这类漏洞时，不能只问“是不是远程”，还要问：

• 谁能在这台机器上跑代码？
• 跑的代码是否可信？
• 是否和其他用户、容器或任务共享同一个内核？
• 是否存在 setuid 程序、敏感凭据、构建密钥、云凭证？
• 出事以后日志和执行链路能不能复盘？

这些问题比“本地/远程”的标签更接近真实风险。

漏洞原理拆解

Copy Fail 的利用思路可以抽象成四个关键环节。

1. 用户态触达 AF_ALG

AF_ALG 是 Linux 暴露给用户态调用内核 crypto 能力的 socket 接口。正常情况下，它可以让用户态程序使用内核里的加密算法实现。

问题不在于“加密算法被破解”，而在于用户态提交的数据如何进入内核处理链路，以及这些数据引用的内存页后面会不会被错误写入。

2. splice() 把文件页缓存带进处理链

splice() 的特点是尽量减少用户态和内核态之间的数据复制。它可以让管道、文件和目标接口之间共享或引用内核里的数据页。

在这个漏洞场景下，攻击者可以借 splice() 把某个可读文件的数据带入 crypto 操作路径。进入 scatterlist 的不只是普通用户缓冲区，也可能是文件在内存里的 page cache。

3. algif_aead 的 in-place 路径放大了风险

algif_aead 曾经引入过 in-place 优化，让 source 和 destination 尽量复用同一条处理链，以减少拷贝。

优化本身不是坏事，但在这里，文件 page cache 引用被放到了后续可能写入的位置。也就是说，一个原本只应该被读取的页，可能因为处理链路设计问题，被当成可写目标的一部分。

4. authencesn 在失败前写入临时数据

公开分析里提到，authencesn 在处理 ESN 相关字节时，会把 destination buffer 当作临时 scratch 空间，并在认证检查失败之前写入少量字节。

正常情况下，这种临时写入不应该影响文件页缓存。但当前面的 in-place 路径把 page cache 带入 destination 位置后，就可能出现“操作最终失败，但写入已经发生”的情况。

这也是 Copy Fail 这个名字的含义：一次本该安全失败的数据处理，把写入带到了不该被写的位置。

page cache 写入为什么麻烦

这个漏洞让防守侧比较头疼的一点，是 page cache 和磁盘文件不完全是一回事。

攻击者如果污染的是页缓存，磁盘上的文件内容未必发生变化。你对磁盘文件做 hash，可能还是原来的结果；但某个进程执行这个文件时，读到的却可能是内存里被改过的缓存页。

这会带来几个问题：

• 传统文件完整性校验可能漏报。
• 取证时如果只看磁盘文件，可能看不到当时实际执行的内容。
• 重启或释放缓存后，某些表面痕迹可能消失，但攻击者提权后的后续动作可能已经落盘。

所以排查这类问题时，不能只盯着“文件有没有被改”。要同时看进程行为、权限变化、异常 root shell、持久化痕迹、账号和凭据访问记录。

哪些环境优先排查

建议先按风险场景分层，不要平均用力。

1. 容器与 Kubernetes 节点

容器共享宿主机内核。如果容器内能触发相关路径，就要考虑节点级风险。尤其是多租户集群、运行用户自定义任务的集群、构建集群、在线实验环境，都应该优先看。

2. CI/CD 与构建系统

自建 GitHub Actions runner、GitLab Runner、Jenkins agent、构建农场是重点。CI 环境经常会执行外部代码、安装依赖、拉取仓库和处理构建产物。一旦 runner 被提权，风险可能影响源码、构建密钥、制品仓库和部署链路。

3. 共享开发机、跳板机、运维机

多用户共享环境里，本地提权的价值很高。低权限用户一旦提权，不仅影响本机，还可能拿到更多内部系统入口。

4. 沙箱、Notebook、AI Agent 执行机

这类环境本来就把“执行能力”开放给用户、脚本、插件或 Agent。Copy Fail 这类漏洞提醒我们：只要底层还共享 Linux 内核，执行沙箱就不能只看应用层隔离。

5. 普通业务服务器

单租户业务服务器不是第一优先级，但如果历史上出现过 Web RCE、弱口令、文件上传、命令执行、被盗凭据等低权限入口，也需要纳入排查。

排查建议

1. 确认内核版本和发行版信息

uname -r cat /etc/os-release

拿到版本后，不要只靠搜索主线版本号。建议查对应发行版公告，看 CVE-2026-31431 是否已经修复或 backport。

2. 检查 algif_aead 模块状态

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

这一步不是漏洞验证，只是判断相关模块是否存在、是否已加载。

3. 观察 AF_ALG 使用痕迹

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

这些命令只能提供线索，不能直接证明被利用。真正的判断还要结合进程、用户、任务来源和日志。

4. 重点看异常提权行为

重点关注：

• 普通用户突然执行 setuid 程序后获得 root。
• CI runner、容器任务、Notebook 进程出现不符合任务预期的 root shell。
• 短时间内出现大量 AF_ALG、splice()、sendmsg()、recvmsg() 相关行为。
• 提权后出现账号变更、SSH key 写入、sudoers 修改、计划任务、systemd 服务变更。
• 构建机、Agent 执行机上出现异常访问源码、制品、云凭据、环境变量的行为。

如果怀疑已经被利用，建议按主机入侵处理，而不是只当漏洞扫描结果处理。

修复和临时缓解

首选：更新内核并重启

内核漏洞最终要靠内核补丁解决。安装修复包以后，要确认正在运行的内核已经切换到修复后的版本，而不是只安装了包但没重启。

uname -r

如果是容器节点、CI runner、沙箱节点，建议优先安排维护窗口。

临时缓解：禁用 algif_aead

如果暂时不能升级，并且确认业务不依赖 algif_aead，可以考虑临时禁用模块：

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

注意，这个动作可能影响少数显式使用 AF_ALG 或相关内核 crypto 接口的应用。生产环境执行前要先评估影响。

临时缓解：限制 AF_ALG socket

对于容器和沙箱环境，可以考虑通过 seccomp、LSM 或平台策略限制不可信工作负载创建 AF_ALG socket。

这个方向更适合平台侧统一做，而不是让每个业务容器自己处理。它的价值在于：即使未来出现类似内核接口利用，也能减少不可信代码触达危险接口的机会。

几个容易误判的点

误判一：不是远程漏洞，所以不用管

如果你的机器不允许任何低权限用户或不可信代码执行，优先级可以下降。但如果它是 CI、容器节点、共享主机、沙箱、Notebook 或 Agent 执行机，本地提权就是很现实的攻击链环节。

误判二：容器隔离可以天然挡住

容器共享宿主机内核。内核本地提权漏洞正好打在这个边界上。容器不是 VM，不能把这类风险简单归为“容器内部问题”。

误判三：文件 hash 没变就没事

Copy Fail 的特殊点在 page cache。磁盘 hash 没变，不代表执行时读到的缓存页没被影响。

误判四：可以直接在生产跑 PoC 验证

不建议这么做。公开 PoC 通常会触碰 setuid 程序和页缓存，即使声称不持久，也可能造成系统状态异常。生产环境应该优先做版本确认、补丁验证和行为排查。

应急处置优先级

可以按下面顺序推进：

1. 先排 Kubernetes 节点、CI runner、沙箱、Notebook、AI Agent 执行机。
2. 再排共享开发机、跳板机、构建机、运维工具机。
3. 排查存在低权限落点风险的业务服务器。
4. 最后处理普通单用户终端和低暴露内部服务器。

如果资源有限，第一批机器建议直接看三个问题：

• 是否运行不可信代码？
• 是否共享同一个 Linux 内核？
• 是否已经安装发行版针对 CVE-2026-31431 的修复包并重启？

这三个问题能快速把风险面收窄。

总结

Copy Fail 真正值得关注的地方，不只是 Linux kernel 又出现了一个本地提权漏洞。

它提醒我们，现在很多平台都在主动提供“执行能力”：CI 执行构建脚本，容器平台运行用户任务，Notebook 运行实验代码，AI Agent 执行命令和工具。过去看起来离攻击者比较远的本地提权，在这些场景里会变得更近。

所以这类漏洞的排查，不应该只停在 CVE 字段上。更重要的是把它放回自己的执行环境里看：

• 谁能跑代码？
• 跑在哪里？
• 和谁共享内核？
• 能不能触达敏感内核接口？
• 提权后能拿到哪些凭据和系统能力？
• 出事以后能不能复盘？

这些问题回答清楚，才算真正完成了这次漏洞预警。

参考资料

• 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