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 的可控写入。这个点很关键攻击者不一定直接改磁盘文件但进程实际执行时可能读到已经被污染的页缓存。本文只做防守分析和排查建议不提供可复制利用步骤。漏洞基本信息项目内容漏洞编号CVE-2026-31431漏洞名称Copy Fail影响组件Linux kernel crypto / algif_aead / authencesn相关接口AF_ALG、splice()漏洞类型本地提权 / page cache 可控写入风险等级HighCVSS 7.8攻击前提本地低权限代码执行典型风险普通用户提权容器、CI、沙箱、Agent 执行环境出现节点级风险修复方向更新内核或安装发行版安全补丁这里有一个排查上的细节不要只看主线内核版本号。很多发行版会 backport 修复内核版本字符串看起来没有变化但补丁已经合入也可能版本看起来接近安全线但发行版还没发布对应修复包。最终应以发行版安全公告、补丁包和实际运行内核为准。为什么本地提权也要重视很多人看到“本地提权”会先松一口气因为它不像远程 RCE 那样可以直接从公网打进来。但现在的基础设施里本地执行入口并不少见CI/CD 会执行外部 PR、构建脚本、依赖安装脚本。Kubernetes 节点会运行多个容器和任务。共享开发机、跳板机、运维工具机可能有多个用户。Notebook、代码沙箱、在线实验环境本来就允许用户跑代码。AI Agent 执行机可能会帮用户运行命令、拉仓库、装依赖、跑测试。在这些场景里攻击者不一定一开始就是 root。他只要拿到普通代码执行就可能借本地提权漏洞继续向上走。所以判断这类漏洞时不能只问“是不是远程”还要问谁能在这台机器上跑代码跑的代码是否可信是否和其他用户、容器或任务共享同一个内核是否存在 setuid 程序、敏感凭据、构建密钥、云凭证出事以后日志和执行链路能不能复盘这些问题比“本地/远程”的标签更接近真实风险。漏洞原理拆解Copy Fail 的利用思路可以抽象成四个关键环节。1. 用户态触达 AF_ALGAF_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 程序和页缓存即使声称不持久也可能造成系统状态异常。生产环境应该优先做版本确认、补丁验证和行为排查。应急处置优先级可以按下面顺序推进先排 Kubernetes 节点、CI runner、沙箱、Notebook、AI Agent 执行机。再排共享开发机、跳板机、构建机、运维工具机。排查存在低权限落点风险的业务服务器。最后处理普通单用户终端和低暴露内部服务器。如果资源有限第一批机器建议直接看三个问题是否运行不可信代码是否共享同一个 Linux 内核是否已经安装发行版针对 CVE-2026-31431 的修复包并重启这三个问题能快速把风险面收窄。总结Copy Fail 真正值得关注的地方不只是 Linux kernel 又出现了一个本地提权漏洞。它提醒我们现在很多平台都在主动提供“执行能力”CI 执行构建脚本容器平台运行用户任务Notebook 运行实验代码AI Agent 执行命令和工具。过去看起来离攻击者比较远的本地提权在这些场景里会变得更近。所以这类漏洞的排查不应该只停在 CVE 字段上。更重要的是把它放回自己的执行环境里看谁能跑代码跑在哪里和谁共享内核能不能触达敏感内核接口提权后能拿到哪些凭据和系统能力出事以后能不能复盘这些问题回答清楚才算真正完成了这次漏洞预警。参考资料CVE 官方记录https://www.cve.org/CVERecord?idCVE-2026-31431CVE JSON 记录https://cveawg.mitre.org/api/cve/CVE-2026-31431Copy Fail 页面https://copy.fail/Xint 技术分析https://xint.io/blog/copy-fail-linux-distributionsoss-security 讨论https://www.openwall.com/lists/oss-security/2026/04/29/23Linux stable 修复提交https://git.kernel.org/stable/c/fafe0fa2995a0f7073c1c358d7d3145bcc9aedd8https://git.kernel.org/stable/c/ce42ee423e58dffa5ec03524054c9d8bfd4f6237https://git.kernel.org/stable/c/a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5