Copy Fail（CVE-2026-31431）排查与修复指南：你的服务器中招了吗

上一篇文章讲了这个漏洞有多严重。这篇来实操——怎么检查你的系统是否受影响，怎么修复，以及紧急情况下怎么缓解。

先说一句：如果你的服务器被多用户共享，或者跑着容器，请立刻检查。 PoC 已公开，脚本化利用，门槛极低。

三步快速排查

第一步：检查内核版本

uname -r

对比以下安全版本表：

如果你的版本低于安全版本，系统可能受影响——还需要第二步确认。

第二步：检查内核配置

漏洞需要 CONFIG_CRYPTO_USER_API_AEAD 内核配置项启用才能利用。

grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

有三种可能的结果：

第三步：检查模块是否已加载

lsmod | grep algif

如果输出中包含 algif_aead 或 algif_skcipher，说明模块已加载，存在风险。

还可以直接测试 AF\_ALG socket 是否能创建：

python3 -c "import socket; socket.socket(38,5,0); print('VULNERABLE')"

如果输出 VULNERABLE，说明系统上可以创建 AF\_ALG socket——这是利用的前置条件。

修复方案

方案一：升级内核（推荐，最彻底）

不同发行版的升级命令：

Ubuntu/Debian：

sudo apt update
sudo apt upgrade linux-image-$(uname -r | cut -d- -f1-2)
# 或者直接全量升级
sudo apt dist-upgrade
sudo reboot

RHEL/Rocky/Alma：

sudo dnf --refresh update 'kernel*'
sudo reboot

Amazon Linux：

sudo yum update kernel
sudo reboot

SUSE：

sudo zypper update kernel-default
sudo reboot

方案二：禁用模块（临时缓解，不重启）

如果因为某些原因不能立即重启服务器，可以先禁用相关模块作为临时措施。

# 卸载已加载的模块
sudo rmmod algif_aead 2>/dev/null
sudo rmmod algif_skcipher 2>/dev/null

# 阻止模块自动加载
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf
echo "install algif_skcipher /bin/false" | sudo tee /etc/modprobe.d/disable-algif-skicipher.conf

注意： 这种缓解方案只对模块方式（=m）生效。如果内核把 CONFIG_CRYPTO_USER_API_AEAD 静态编译了（=y），禁用模块的命令不会有任何效果，必须升级内核。

方案三：seccomp 限制容器

对于容器环境，可以通过 seccomp 策略禁止创建 AF\_ALG socket（family=38），作为容器逃逸的防护层：

{
  "syscalls": [
    {
      "names": ["socket"],
      "action": "SCMP_ACT_ERRNO",
      "args": [
        {
          "index": 0,
          "value": 38,
          "op": "SCMP_CMP_EQ"
        }
      ]
    }
  ]
}

验证修复

升级/重启后重新执行排查步骤：

uname -r
# 确认内核版本 >= 安全版本

python3 -c "import socket; s=socket.socket(38,5,0); (s.bind(('aead','authencesn(hmac(sha256),cbc(aes))')) or print('NOT FIXED')) if s else None" 2>/dev/null || echo "FIXED"

如果输出 FIXED，说明缓解措施生效了。

几个常见场景的处理建议

场景一：云服务器（ECS/CVM）

大多数云厂商已经在镜像层面发布了更新内核的安全版本。如果你用的是厂商提供的官方镜像：

1. 检查是否有可用的内核更新：sudo apt list --upgradable | grep linux-image
2. 如有，升级并重启
3. 如果云厂商的控制台提供了「安全更新」一键修复，直接用

注意： 重启云服务器意味着 IP 可能变化（如果用的弹性公网 IP 没问题，经典网络需要注意）。

场景二：容器/K8s 节点

K8s 节点的修复需要滚动重启节点，属于高危操作。

建议顺序：

1. 先对测试节点做内核升级 + 重启验证
2. 确认业务无影响后，对生产节点做滚动更新
3. 在完成所有节点升级前，保持 seccomp 策略开启

场景三：嵌入式设备/IoT

如果设备运行的是旧版本内核（4.x 甚至 3.x），但设备上没有 AF_ALG 或 splice() 的使用场景，实际上风险较低。但为了安全，建议还是检查内核配置并升级。

这个漏洞教会我们什么

Copy Fail 的存在时间（2017–2026）说明了一件事：内核安全审计的盲区往往在子系统的交界处。 AF\_ALG 属于加密子系统，splice() 属于文件系统，authencesn 属于 IPsec 协议实现——三个不同的世界在一条代码路径上相遇，碰撞出了这个漏洞。

给服务器管理员的建议：

1. 保持内核更新是底线。LTS 发行版会 backport 安全补丁，但前提是你得安装它们
2. 多用户共享的服务器是高风险区。只要有一个用户能被利用，整个系统就不安全了
3. 容器不代表隔离。内核级别的漏洞可以绕过容器的命名空间隔离，不要让容器里的普通用户拥有高危环境的访问权
4. 关注安全公告。如果你运行的是生产环境，订阅 Ubuntu Security Notice、RHSA、Debian Security Advisory——你不需要第一时间知道，但需要在一周内完成修复

快速参考

# 一键排查脚本
echo "=== Kernel ===" && uname -r && 
echo "=== Config ===" && grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r) && 
echo "=== Module ===" && lsmod | grep algif && 
echo "=== Socket test ===" && python3 -c "import socket; socket.socket(38,5,0); print('AF_ALG available'); socket.socket(38,5,0).bind(('aead','authencesn(hmac(sha256),cbc(aes))')); print('CRITICAL: authencesn usable')" 2>/dev/null || echo "Safe"

把这行保存为 check-cve-2026-31431.sh，在你管理的每一台服务器上跑一遍。

如果你的系统在射程内，不要慌——升级内核 + 重启，问题解决。