潜伏9年,不到1kb脚本秒提root:Linux＂Copy Fail＂核弹级漏洞!k8s、ci/cd、容器基建运维速看

一个普通用户，一行命令，100%概率拿到root权限。 不需要竞态条件，不需要针对特定发行版编译，不需要任何特殊权限。这个潜伏在Linux内核中近9年的逻辑缺陷，正在让全球几乎所有的Linux服务器暴露在致命威胁之下。

一、它有多可怕？

如果你是一名系统管理员，看到"100%成功率"和"仅需普通用户"这两个关键词组合，后背应该已经开始冒冷汗了。

这不仅仅是一个本地提权漏洞——在容器化环境中，它更是一个容器逃逸原语，攻击者可以从Pod直接跳到宿主机。

二、漏洞全景：一张图看懂攻击链

整个攻击过程不需要任何概率性操作，没有任何竞态窗口——每一步都是确定性的。

三、漏洞根因：一次"优化"引发的灾难

3.1 三个关键子系统的交汇

这个漏洞并非出现在某个孤立模块中，而是位于三个内核子系统的交汇处：

单独看任何一个子系统，都没有安全问题。但当它们组合在一起，一个致命的逻辑链条就形成了。

3.2 致命的2017年"优化"

2017年，一个看似无害的提交 72548b093ee3 将 algif_aead 的操作方式从非原地（out-of-place）改为了原地（in-place）：

核心问题：2017年之前，源（src）和目标（dst）是两个独立的散列表，页缓存页面在只读的src中，临时写入只会影响用户的缓冲区。2017年的"优化"让它们变成了同一个散列表，通过 sg_chain() 将页缓存页面挂在了可写位置——authencesn 的临时写入直接落入了页缓存。

3.3 关键的4字节写入

authencesn 在解密时需要重组ESN（扩展序列号）字节。它使用目标缓冲区作为临时工作区：

即使HMAC校验失败、即使 recvmsg() 返回了错误——那4个字节已经被写入了页缓存，而且不会被恢复。这就是漏洞名称"Copy Fail"的由来：复制操作失败了，但副作用已经产生。

四、攻击还原：732字节如何秒杀Linux

攻击者选择的覆盖目标是 /usr/bin/su 这样的 setuid-root 程序。当内核从页缓存加载这个被篡改的二进制文件时，攻击者的shellcode就会以root权限执行。

对比一下历史上著名的Linux提权漏洞：

Copy Fail 是继 Dirty Pipe 之后，又一个兼具"无需竞态"和"100%可靠"两个顶级属性的漏洞。而且它的利用代码比 Dirty Pipe 更小、更简洁。

五、影响范围：谁中招了？

5.1 受影响的内核版本

5.2 已确认受影响的发行版

已修复的内核版本：6.18.22+、6.19.12+、7.0+。

5.3 容器环境面临的风险

这一点需要特别强调：

关键事实：页缓存是内核全局共享的资源，不受容器命名空间隔离。一个容器内的攻击者修改了页缓存，等于影响了宿主机上所有容器的文件系统视图。

Copy Fail 不仅仅是本地提权——它是容器逃逸原语。研究人员已预告将在后续文章中展示 Kubernetes 环境下的完整利用链。

六、AI辅助发现：新范式已来

这个漏洞的发现过程本身就值得关注。

传统上，这类深层逻辑漏洞需要经验丰富的安全研究员耗费数月手工审计才能发现。而 AI 辅助工具将审计 crypto/ 整个子系统的耗时压缩到了约一小时。

这意味着：

• 内核中可能还有更多类似的"沉睡"逻辑缺陷等待被发现
• AI 正在从根本上改变漏洞发现的效率和规模
• 及时打补丁的紧迫性比以往任何时候都高

七、系统管理员应对方案

7.1 紧急缓解措施（立即执行）

如果你现在还无法升级内核，以下措施可以在几分钟内阻断攻击路径：

方案一：禁用 algif_aead 内核模块（推荐）

# 禁止加载 algif_aead 模块
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf

# 尝试卸载已加载的模块（如果正在使用则跳过）
rmmod algif_aead 2>/dev/null || true

# 验证模块已被禁用
cat /etc/modprobe.d/disable-algif.conf
modprobe --show-depends algif_aead 2>&1

影响评估：这一操作对绝大多数生产环境几乎零影响。AF_ALG 是内核加密子系统的用户空间接口，而绝大多数应用程序（SSH、OpenSSL、LUKS、IPsec、kTLS）使用内核内部API或用户空间库，不走 AF_ALG。仅当你的系统显式配置了 OpenSSL 的 afalg 引擎或自定义的 AF_ALG 用户程序时才会受影响。

方案二：通过 seccomp 阻止 AF_ALG 套接字创建（适用于容器）

在 Kubernetes Pod 的安全策略中添加 seccomp 规则，阻止创建 AF_ALG 类型的套接字：

# Kubernetes Pod 安全策略示例
apiVersion: v1
kind: Pod
metadata:
name: hardened-pod
spec:
securityContext:
seccompProfile:
type: Localhost
localhostProfile: block-afalg.json

# block-afalg.json seccomp 配置
{
"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{
"names": ["socket"],
"action": "SCMP_ACT_ERRNO",
"args": [
{
"index": 0,
"op": "SCMP_CMP_EQ",
"value": 38
},
{
"index": 1,
"op": "SCMP_CMP_EQ",
"value": 5
}
],
"comment": "Block AF_ALG(38) SOCK_SEQPACKET(5) to prevent CVE-2026-31431"
}
]
}

7.2 根本解决方案：升级内核

7.3 各发行版修复命令速查

7.4 生产环境补丁部署建议

7.5 高风险环境特别提醒

如果你的环境属于以下任何一种，建议立即采取缓解措施：

• 共享主机 / 虚拟主机：一个用户可提权至root，访问所有租户数据
• Kubernetes 集群：攻击者可从Pod逃逸到宿主机
• CI/CD Runner（GitHub Actions、GitLab Runner、Jenkins Agent）：执行PR中的任意代码即可获取Runner的root权限
• Jupyter Notebook 服务器：用户可在Notebook中直接运行利用代码
• 多用户SSH服务器：任何普通用户可提权为root

八、技术反思：一个"正确"的优化如何变成灾难

回顾这个漏洞，有几个值得深思的教训：

1. 优化的代价：2017年的 in-place 优化在性能上是合理的，但它悄悄打破了一个隐式的安全假设——"目标缓冲区只包含用户数据"。当页缓存页面通过 splice() 被链入目标缓冲区时，这个假设就不成立了。

2. 组合的安全性：AF_ALG、splice() 和 authencesn 各自都是安全的。但当它们组合在一起时，交互的语义发生了根本变化。这是复杂系统安全的核心挑战。

3. AI时代的威胁：这个漏洞由AI辅助工具在约1小时内发现。如果白帽子能做到，黑帽子同样可以。漏洞发现的时间窗口正在急剧缩短。

九、总结：行动清单

Copy Fail 不会是最后一个"完美的"提权漏洞，但可以是你的系统第一次因为及时打补丁而幸免于难的那一个。

参考资料：

• NVD CVE-2026-31431
• Red Hat CVE Advisory
• Ubuntu CVE Advisory
• oss-security 邮件列表披露
• GitHub PoC 仓库