2.1 三个技术要素的异常耦合#

这个漏洞的根源是三个技术要素之间的异常交互：

1. AF_ALG 加密套接字接口：Linux 内核提供的用户态访问加密功能的通道。应用程序通过 AF_ALG socket，可以将数据交给内核进行加解密运算，效率高于用户态实现。
2. splice() 系统调用：零拷贝数据搬运接口，可以在两个文件描述符之间直接传递数据，无需经过用户空间。典型用法是将文件内容直接送入 socket，避免数据从内核态拷贝到用户态再拷贝回内核态的多余开销。
3. 2017 年引入的“原地操作”（in-place）优化：在 Linux 内核 4.14 版本的一次代码提交中，开发者为 algif_aead（AEAD 算法的用户态接口）加入了一项性能优化——让加密操作在原地缓冲区进行，不再对输入输出做严格分离。这个优化的本意是减少内存拷贝、提高吞吐量，但客观上打破了“输入缓冲区只读”的假设，埋下了安全缺陷。

2.2 异常发生的完整路径#

要理解 Copy Fail 漏洞如何被利用，需要追踪整个操作链条：

第一步：打开目标和加密通道。 攻击者先用 open() 打开一个目标文件（比如 /usr/bin/su），得到一个普通的文件描述符。同时用 socket() 创建一个 AF_ALG 类型套接字，绑定到 AEAD 算法（具体是 authencesn 模板），得到加密套接字描述符。authencesn 是 Linux 内核加密子系统中专门处理带扩展序列号（ESN）的认证加密模板，IPsec 协议依赖该模块。

第二步：用 splice() 把文件送入加密通道。 正常情况下，用户态应用准备加密数据时，会把数据拷贝到 AF_ALG socket 关联的缓冲区，内核再把缓冲区内容送入加密引擎处理。而 splice() 允许直接关联两个描述符的内核内存——用一个 splice() 调用，将目标的文件描述符直接连接到加密套接字上，这意味着文件的页缓存页（Page Cache Page）被纳入加密操作流程，而非独立的临时缓冲区。

第三步：触发 AEAD 解密流程。 攻击者向该加密套接字发送一个经过特殊构造的 AEAD 操作请求（需要包含一个假的认证标签）。这个操作会触发加密子系统内部的 authencesn 解密路径。在正常设计中，解密操作输出的数据应该被写入一个临时缓冲区，不会影响原始数据。

第四步：页缓存被误写。 但由于 2017 年引入的“原地操作”优化，内核的 algif_aead 模块在特定条件下直接复用输入页作为目标页，把解密输出的数据写回到了页缓存中。更具体地：在 crypto_authenc_esn_decrypt 函数中，控制数据（来自用户空间）被写入目标区域，而修复前的逻辑使该目标区域指向了文件页缓存。于是，本来只读的页缓存页被写入了受控的 4 个字节。

2.3 为什么会成：三个机制的“危险握手”#

上述四步能够串联成一次成功的攻击，依赖于以下三个机制的同时存在：

• AF_ALG socket 向用户态暴露了内核加密功能。如果没有这个接口，攻击者根本无法调用内核加密引擎。
• splice() 系统调用提供了绕过用户空间内存的直接数据通道。没有 splice()，攻击者无法将文件页缓存送入加密操作。
• authencesn 解密操作会向目标区域写入数据。而修复前的缺陷使该目标区域被错误地设置成了文件页缓存，而不是临时缓冲区。

当三个机制同时启用时，攻击者就可以将加密操作的输出重定向到文件页缓存，从而篡改内存中的文件内容。整个过程不需要竞争条件，不需要内存地址泄露，也不需要预知内核偏移量。攻击者仅需一个普通用户账号，一条路径就能直达 root。

4.1 页缓存是宿主机共享资源#

在 Linux 系统中，页缓存是宿主机级别的全局资源。当宿主机将文件读入内存时，数据存放在统一的页缓存中。Docker 和 Kubernetes 容器在底层与宿主机共用同一个内核，也就共用同一份页缓存。当宿主机上的某个文件被多个容器频繁读取时，页缓存中只有一份副本被共享访问。

这个设计是出于性能考虑——节省了内存，加速了文件访问。但当页缓存可被任意写入（如 Copy Fail 漏洞所允许的那样）时，这个共享性质就成了攻击的放大器。

4.2 攻击者从容器到主机的逃逸#

利用 Copy Fail，容器内的普通用户可以进行以下攻击：

• 第一步：确认容器内核版本。 攻击者在容器内运行 uname -r，确认宿主机内核版本在受影响的范围内。
• 第二步：找到宿主机关键 setuid 二进制文件的内存地址。 容器虽然无法直接访问宿主机的 /usr/bin/su（容器有自己独立的文件系统），但因为宿主机加载的文件也在系统的页缓存中，攻击者可以通过跨容器的页缓存共享来定位。一个路径是：如果宿主机正在运行某个容器的共享映像文件，该文件的页缓存位置在宿主机全局可见。
• 第三步：执行 Copy Fail 篡改页缓存。 攻击者利用 Copy Fail payload，将 4 字节控制数据写入页缓存中目标文件的对应位置。由于页缓存是全局共享的，该写入会同时污染宿主机的页缓存。
• 第四步：获得宿主机 root 权限。 当宿主机或其他容器再次执行被污染的 setuid 程序（如 su 或 sudo）时，加载的是已被篡改的页缓存内容，直接以 root 权限执行攻击者的恶意代码。攻击者因此获得宿主机的 root shell，实现了容器逃逸。

这一攻击路径不需要攻击者获得宿主机文件系统的访问权，甚至不需要知道宿主机的具体文件路径——只要攻击者能够推测哪些文件被共享、如何被读取，就可以在容器内部完成逃逸。

4.3 受影响的高危场景#

根据多个安全厂商的分析，以下场景面临最高风险：

对比 Dirty Pipe，Copy Fail 在云原生场景的威胁更大。Dirty Pipe 虽然也能实现页缓存污染，但依赖于目标文件是只读且能够获得写入描述符，这在容器内的受限文件系统下实现逃逸较为复杂。而 Copy Fail 只需要目标文件可读（几乎全部 setuid 程序满足此条件），就能直接污染页缓存，攻击面明显更宽，更适用于容器逃逸和跨租户攻击。

5.1 上游补丁：回退“原地优化”#

Linux 内核主线修复提交为 a664bf3d603d，提交说明显示该修复将 algif_aead 回退到 out-of-place 操作，移除此前 in-place 处理带来的复杂逻辑；该提交标记修复了 2017 年引入的相关变更。

具体而言，补丁做了两件事：

• 移除 algif_aead 模块中危险的原址优化逻辑，强制加密操作的输出写入临时缓冲区，而非复用输入页；
• 确保页缓存页面不再进入可写的 scatterlist（分散列表），防止攻击者通过加密套接字误写只读页缓存。

这两个改变直接切断了漏洞的触发路径。攻击者无法再控制加密操作的输出目标指向页缓存。即使攻击者能够调用 AF_ALG 接口、能够完成 splice() 跨文件描述符的数据搬运，最终的写入目标也仅限于内核分配的临时缓冲区——该缓冲区在操作完成后被释放，不会对任何持久化数据造成影响，也不会污染页缓存。

5.2 安全版本列表#

根据公开信息，各内核分支的安全版本如下：

上述版本范围的另一边界是 Linux 内核 4.14——漏洞引入的起点。如果你的内核版本介于 4.14 与上述安全版本之间（不含安全版本），则漏洞存在。

5.3 各大发行版状态#

部分发行版的早期响应存在延迟——Red Hat 曾表示考虑延期推送补丁，但后来更新了安全公告，与主流发行版保持一致节奏。SUSE 明确确认了影响范围，涵盖 SLES 15（所有 Service Pack）、SL Micro、Leap 15/16，12 SP5 及更早版本不受影响。

5.4 修复后的差异#

升级到安全版本后，加密子系统回退到 out-of-place 模式。加密操作的输入和输出被强制分开——输出数据写入一个全新的临时缓冲区，由内核自动管理，在操作完成后释放。文件页缓存在整个加密操作过程中保持只读，不会被写操作触及。

这一改变带来的性能代价是额外的内存拷贝——加密操作需要将输出从临时缓冲区拷贝回用户缓冲区，而非原地复用页。这就是 2017 年引入该优化的初衷：提高性能。但安全性的代价大于性能收益时，回退是正确的选择。

6.1 禁用 algif_aead 内核模块（通用方案）#

algif_aead 是漏洞的入口。禁用该模块后，AF_ALG 套接字无法绑定 AEAD 算法，攻击者无法触发异常路径。禁用该模块不会影响常规的 LUKS 磁盘加密、IPsec、OpenSSL、SSH、HTTPS 等常见功能。

具体操作：

1
# 1. 创建配置文件，禁止模块自动加载
2
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif.conf
3
# 2. 立即卸載已加载的模块（卸载前确保无活动 AEAD socket）
4
sudo rmmod algif_aead 2>/dev/null || true
5

6
# 验证模块已不在加载列表中
7
lsmod | grep algif_aead || echo "模块已禁用"

注意事项：禁用模块前需评估业务系统中是否有应用程序通过 AF_ALG 接口调用 AEAD 算法（如某些 VPN 实现）。若有此类依赖，禁用会造成功能异常。

6.2 seccomp 策略阻断 AF_ALG socket（容器环境最优方案）#

在容器环境中，禁用内核模块不是总能做到的（需宿主机权限）。更合适的办法是利用 seccomp 直接限制容器内进程的系统调用，阻止 socket() 系统调用创建 AF_ALG 类型的套接字。

创建 block-af_alg.json：

1
{
2
  "defaultAction": "SCMP_ACT_ALLOW",
3
  "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_AARCH64"],
4
  "syscalls": [
5
    {
6
      "names": ["socket"],
7
      "action": "SCMP_ACT_ERRNO",
8
      "args": [
9
        {"index": 0, "value": 38, "op": "SCMP_CMP_EQ"}
10
      ]
11
    }
12
  ]
13
}

将该 seccomp profile 应用到 Kubernetes Pod 或 Docker 容器中。通过这种方式，容器内进程在尝试创建 AF_ALG socket（domain = 38）时会被直接阻止，即使宿主机内核仍存在漏洞，攻击也无法从容器内完成。

6.3 临时降低攻击面（主机级应急）#

如果以上方案不可行，可以考虑临时降低系统的暴露面：

• 限制非必要的本地用户登录（SSH 仅允许信任用户登录）；
• 在 CI/CD 流水线中，将不可信代码放在隔离更强的专用 Runner 上，而非生产级的多租户基础设施；
• 在 Kubernetes 环境，强制使用 HostUsers: false 或 runAsNonRoot: true 降低攻击影响面；
• 给敏感 setuid 二进制（如 /usr/bin/su）临时移除执行权限（如 chmod 000 /usr/bin/su），但这会影响系统正常功能，极不推荐用于生产环境，仅作为临时实验方案。

注意：清理页缓存（sync && echo 3 > /proc/sys/vm/drop_caches）无法阻止新的攻击。该操作只能清除已被篡改的内存镜像，不能封堵漏洞本身。攻击者可以在任意时刻再次执行 exploit。

7.1 核心风险评估#

CVE-2026-31431 之所以被称为“史诗级”漏洞，原因有三：

7.2 响应时间线#

根据公开信息推测的时间线：

• 2026 年 3 月 23 日：Theori 研究员 Taeyang Lee 向 Linux 内核安全团队报告漏洞。
• 2026 年 4 月 1 日：上游主线补丁 a664bf3d603d 被合并。
• 2026 年 4 月 22 日：CVE-2026-31431 编号正式分配。
• 2026 年 4 月 22 日～4 月 29 日：各发行版内部测试并推送安全更新。
• 2026 年 4 月 29 日：Theori 公开披露漏洞及 PoC。
• 2026 年 4 月 30 日：国内外各大安全社区、厂商发布紧急安全通告和安全更新。
• 2026 年 4 月 30 日以后：公有云厂商（AWS、阿里云、华为云、OVHcloud、腾讯云等）陆续推送修复版镜像和安全更新。

7.3 对云原生环境的长期影响#

Copy Fail 的披露引发了云服务商和容器平台的紧急安全响应，核心问题在于无法通过常规隔离措施阻止容器内利用该漏洞逃逸到宿主机。传统的容器安全假设——容器内低权限进程不应影响宿主机——被这个漏洞打破了。

对于 Kubernetes 集群的管理员，以下是核心安全策略建议：

• 节点立即升级内核，将宿主机内核升级到安全版本是最彻底的解决方案。
• 限制容器创建 AF_ALG socket：在 Pod Security Standards 或准入控制器级别，添加 seccomp profile 阻断该行为，作为升级前的过渡措施。
• 审查 CI/CD 流水线中 Runner 使用的镜像。如果基础镜像来自受影响的版本（2026 年 4 月初之前构建的），默认存在漏洞。
• 启用节点级的异常行为检测：利用 eBPF 或 HIDS（如奇安信椒图）监控 AF_ALG socket 的异常创建频率，作为安全事件的早期预警指标。
• 审计高风险命名空间，检查是否有疑似提权的痕迹（异常的 su/sudo 执行、非 root→root 的权限跃迁的 shell 会话）。