微软警告 “Dirty Frag” Linux 高危内核漏洞已遭黑客利用,速加固修复!

只需 732 字节的利用代码，任意本地用户即可获取 root 权限。这个自 2017 年就潜伏在内核加密子系统中的漏洞，正在影响全球数以百万计的 Linux 服务器。

2026 年 5 月，Linux 内核被披露存在一个严重的本地权限提升漏洞：

CVE-2026-31431，代号 "Copy Fail"。

攻击者只需利用 AF_ALG 加密接口与 splice() 系统调用的组合，即可向任意可读文件的页缓存中写入受控的 4 字节数据。通过篡改 setuid 二进制文件（如 /usr/bin/su），无需竞争条件、无需重试，即可直接获得 root 权限。

更致命的是：该写入不会触发磁盘脏页回写，这意味着修改可以持久化保留在内存中，即使文件在磁盘上未被修改，内核仍会执行被篡改的页缓存内容。

目前，该漏洞的完整利用细节和 POC 已公开，全球所有主流 Linux 发行版均受影响。

📋 漏洞速览

漏洞原理：732 字节如何直达 Root？

要理解这个漏洞，我们需要从 Linux 内核的加密子系统说起。

AF_ALG 与内核加密接口

Linux 内核提供了一个名为 AF_ALG 的套接字族（family 38），允许用户空间程序直接调用内核的加密算法。这个功能本身没有问题，但问题出在它与 splice() 系统调用交互时的实现细节上。

2017 年的那个"优化"

2017 年，内核提交 72548b093ee3 引入了一个就地（in-place）操作优化：将 splice() 传递过来的目标文件页缓存页面，直接链入可写的输出散列表（scatterlist）。

这个优化在当时看起来完全合理——减少内存拷贝，提升性能。但它忽略了一个关键的安全假设。

authencesn 的 4 字节越界写入

当 authencesn 加密模板与 algif_aead 模块组合使用时，问题就出现了。

authencesn 在实现 IPsec 扩展序列号（ESN）支持时，需要在解密过程中重排认证数据中的序列号字节。为此，它会将接收缓冲区偏移 assoclen + cryptlen 的位置作为临时存储空间，写入 4 字节数据。

正常情况下，这个写入发生在接收缓冲区内部。但当 AF_ALG 通过 recvmsg() 触发解密操作时，该写入会跨越接收缓冲区边界，直接覆盖链在后面的页缓存页面。

简单来说：

内核在解密时，往一个它认为"安全"的位置写了 4 个字节。但由于 scatterlist 的链式结构，这 4 个字节实际上写到了目标文件的页缓存里。

从 4 字节到 Root

4 字节听起来很少，但在 Linux 系统中，这已经足够致命：

1. 攻击者可以打开任意可读文件
   （如 /usr/bin/su）
2. 通过 splice() 将该文件的页缓存页链接到 scatterlist
3. 触发 authencesn 解密操作，4 字节越界写入到页缓存
4. 执行该文件，内核使用被篡改的页缓存内容
5. Root 权限到手

整个过程：

• 不需要竞争条件
•  不需要反复重试
•  不需要特殊权限（本地普通用户即可）
•  不会触发磁盘脏页回写（修改保留在内存中）

根据研究人员的演示，完整的利用代码仅有 732 字节。

影响范围

这次漏洞的影响范围几乎覆盖了所有仍在维护的主流 Linux 发行版。

从 Ubuntu 18.04 到最新的 Ubuntu 25.10，从 Debian 11 到 Debian 13，从 RHEL 8 到 RHEL 10，以及 Amazon Linux、Rocky Linux、openSUSE 等，无一幸免。

这意味着全球数以百万计的服务器、云实例、容器和物联网设备都可能受到影响。

如何排查与修复？

第一步：检查你的内核版本

# 检查当前内核版本uname -r

对比下方的安全版本表，如果你的内核版本在受影响范围内，请立即采取行动。

第二步：检查加密模块配置

# 检查内核配置grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-$(uname -r)

可能出现以下三种情况：

# 检查模块是否已加载lsmod | grep algif# 检查 AF_ALG socket 是否可创建python3 -c "import socket; socket.socket(38,5,0); print('VULNERABLE')"

第三步：修复方案

方案一：升级内核（推荐）

各发行版官方已发布安全更新：

以 Debian 为例：

# 更新系统sudo apt updatesudo apt upgrade linux-image-amd64# 重启生效sudo reboot# 验证版本uname -r

方案二：临时缓解措施

如果短期内无法升级内核，可以通过禁用 algif_aead 模块来降低风险：

# 禁用内核模块加载echo"install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf# 卸载已加载模块rmmod algif_aead 2>/dev/null

验证缓解是否生效：

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

⚠️ 注意：对于静态编译进内核的系统（如 RHEL/CentOS/Rocky Linux/AlmaLinux 8、9、10），此缓解措施无法生效，必须升级内核。

方案三：容器环境加固

如果你的系统运行容器，可以通过 seccomp 禁止 AF_ALG socket 创建：

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

第四步：Ubuntu 用户特别注意

Ubuntu 官方暂未发布内核更新补丁，但已发布 kmod 软件包更新，该更新会禁用 algif_aead 模块的加载。建议受影响用户尽快更新：

sudo apt updatesudo apt upgrade kmod

详细信息可参考：

https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available

写在最后

732 字节。从普通用户到 root。

这个漏洞再次提醒我们几个重要的安全原则：

1. 性能优化不等于安全：
   2017 年的那个 in-place 优化提升了性能，却引入了近十年的安全隐患
2. 内核安全需要持续关注：
   即使是经过严格审查的开源内核，也会有盲区
3. 及时更新是最佳防御：
   在 POC 已公开的情况下，升级是唯一可靠的解决方案

如果你管理的 Linux 服务器还在运行上述受影响版本，现在就是升级的最佳时机。

参考来源：

• https://copy.fail/
• https://xint.io/blog/copy-fail-linux-distributions
• https://github.com/theori-io/copy-fail-CVE-2026-31431/
• https://unit42.paloaltonetworks.com/cve-2026-31431-copy-fail/
• https://nvd.nist.gov/vuln/detail/CVE-2026-31431
• https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available

你的服务器内核版本是多少？已经打上补丁了吗？ 

敬畏生产，网络安全不容小觑。