2026 年 4 月 29 日，韩国 Theori / Xint 团队（研究员 Taeyang Lee，创始人 Brian Pak）公开 Linux 内核漏洞 Copy Fail，正式编号 CVE-2026-31431。一段 700 多字节的 Python 投放器（实际经过混淆 + zlib 压缩，里面带一个 ELF binary payload——不是纯 stdlib，详见后文披露争议），把普通用户提到 root，影响 2017 年至今多个主流 Linux 发行版。
核心结论先说在前：这不是远程 RCE，是本地提权；但容器、共享 CI、多租户主机这类场景下，"普通用户"就足够危险。桌面用户更新内核 + 重启就行；服务器和容器主机优先升内核。
这篇拆五件事：漏洞根因、技术原理（说人话）、影响范围、披露争议、中文用户怎么办。
漏洞位置：
- • Linux 内核加密子系统
algif_aead 模块 + authencesn 模板 - • 引入时间：2017 年 8 月 一次"in-place 优化"提交（72548b093ee3）
- • 影响 2017 年至今多个主流发行版 编译的内核（具体是否受影响取决于编译配置和回合补丁）
- • 已验证受影响：Ubuntu 24.04 / RHEL 10.1 / SUSE 16 / Amazon Linux 2023 / Debian / Arch / Fedora / Rocky / Alma / Oracle 等
- • CVSS 7.8（高危），但只能本地利用，不是远程 RCE
披露时间线：
- • 2026-03-23：Theori 报告给 Linux 内核维护者
- • 2026-04-01：mainline 合入 patch（commit a664bf3d603d）
- • 2026-04-22：分配 CVE-2026-31431
二、技术原理（说人话）
内核给 IPsec 做加密时有个叫 authencesn 的算法，2017 年有人为了少拷贝一次内存做了"in-place 优化"——让加密的输入和输出共用同一块内存。
问题是：
- 1. 普通用户开内核加密 socket（AF_ALG），告诉内核"用 authencesn 模板"
- 2. 用
splice() 把 /usr/bin/su 这种 setuid 二进制塞进 socket——这一步内核不会拷贝文件，直接把 page cache 页（内存里的文件副本）的指针塞进加密缓冲区 - 3. 加密算法跑起来后，会往"输出缓冲区某个偏移位置"写 4 字节临时数据——这 4 字节写进了文件在内存里的副本
- 4. 反复跑这个流程，把 shellcode 一次 4 字节地拼进
/usr/bin/su 的内存副本 - 5. 最后调用
su——内核加载的是被改过的内存版本，shellcode 以 root 身份执行
打个比方：
你不能改图书馆的原书（磁盘文件），但能修改"借出去给读者看的那本副本（内存里的 page cache）"。下个想看书的人（execve）拿到的就是改过的副本，而书架上的原书没动。
关键性质：
- • 这是一个 straight-line logic bug——没有竞态、不需要内核地址泄漏、不需要 ROP gadget
- • 一份投放器在已测试的多个主流发行版上稳定复现（不是"跑遍所有发行版"——Alpine 因
/bin/su 权限不同打不通这条具体路径，嵌入式/定制内核要单独验证） - •
md5sum、AIDE 这种校验磁盘文件的工具完全检测不到——磁盘上 /usr/bin/su 字节没变
这条最让 sysadmin 头大：你的入侵检测可能永远不会响，攻击者只在 page cache 里改东西。
三、影响范围
- • 默认配置基本就中招——
algif_aead 在 Fedora / RHEL 是编译进内核的（不是模块），没法 modprobe blacklist - • 需要本地 shell（不是 0-click 远程），但容器逃逸、共享主机、CI runner 这些场景里"普通用户"就足够危险
- • Alpine 因为
/bin/su 的权限设置不一样，这条具体路径打不通——但漏洞本身还在
实际的高危场景：
- • 共享 CI runner：你给团队提供一个共享 runner，团队里任何人都能在上面跑代码——其中一个人就能拿 root，能看到所有人的 secrets
- • 多租户容器主机：Kubernetes node 上跑多家用户的 pod，从 pod 提权到 host root
- • 公开的 Jupyter Notebook 服务：用户能跑 Python 就能跑 PoC，从普通用户拿 root
- • 被入侵的 Web 服务：攻击者通过 Web 漏洞拿到 www-data 这种低权限 shell，靠 Copy Fail 直接升 root
桌面用户相对没那么紧——攻击者要先在你电脑上拿到 shell 才能用这个漏洞，但能拿 shell 通常已经损失很大了。
四、披露争议
Lobsters 上的讨论暴露了两个问题：
1. "纯 stdlib" 是标题党
PoC 声称是 700 多字节"纯 Python 标准库"脚本。Lobsters 用户 dzwdz（97 赞）指出：这脚本经过混淆 + zlib 压缩，解开后包含一个 ELF 二进制 payload。"stdlib only"的说法不严谨。dzwdz 自己后来发了一份未混淆版本到 sourcehut。
写文案时不要照抄"732 字节纯 Python"——准确说法是"700 多字节的 Python 投放器，里面带 ELF payload"。
2. 没走标准披露流程
技术披露应该走 linux-distros@vs.openwall.org[1] 列表，让所有主流发行版有 5-14 天的 embargo 时间准备补丁。Lobsters 用户 technomancy（35 赞）和其他几位维护者指出：Theori 没走这条路。
后果：
- • 公开时 Debian stable / RHEL 当时还没补丁
- • 这意味着 4-29 公开当天，很多生产服务器是裸的
虽然 Theori 走了内核维护者直报路径（mainline patch 4-1 合入），但没同步给发行版打包者这件事，是这次披露最被诟病的点。
五、中文用户怎么办
WECHATIMGPH_6
1. 桌面用户
# Ubuntu / Debiansudo apt update && sudo apt upgradesudo reboot# Fedora / RHELsudo dnf update kernelsudo reboot# Archsudo pacman -Syusudo reboot
把内核升到 4 月底之后的版本，重启。
2. 服务器 / 容器主机（更紧迫）
本地提权对单租户机器影响小，对多租户机器、共享 CI、容器宿主机是高危。
- • 没法升的临时方案：给不可信工作负载加 seccomp 拦掉
socket(AF_ALG) 这个 syscall - • 容器场景：Kubernetes 上加 PodSecurityContext / seccomp profile
3. 嵌入式 / 老内核
⚠️ 不要只看年份——是否受影响取决于：内核版本、具体编译配置、发行版有没有回合补丁、有没有 SELinux/seccomp/AppArmor 等额外控制层。能升就升，不能升的话查你的发行版安全公告 + cat /proc/version 加上跑 PoC（在测试机上）实际验证，不要靠"2017 之后默认都中"这个判断。
4. 国内云主机
阿里云、腾讯云、华为云的官方公告未独立查到——上你自己用的那家云的 security center 看公告，通常 2-3 天内会有修复推送。
六、和"shell 太锋利"主题的关联
昨天那篇 SSH 文章讲的是别把 shell 直接交给 AI，因为权限边界一旦让出去就收不回。Copy Fail 是同一类问题的另一面——
就算你不给 AI shell，本地的 root 提权漏洞本身也意味着"普通用户"和"root"之间那道墙，可能只隔着 732 字节的脚本。
Linux 的权限模型靠的是 setuid 二进制和内核检查，但只要内核里某个 2017 年的优化提交埋了雷，墙就有缝。
这件事提醒的是：权限边界从来不是绝对的，是当前已知漏洞数为零的临时状态。
- • 你的开发机给 AI 装了 sandbox 和最小权限 token，这一层是你能控制的
- • 你的 CI runner、容器主机、共享服务器，这一层依赖内核 + 发行版的安全
- • 内核里有 9 年没人发现的 bug，这一层是你完全没法控制的
唯一的对策是多层纵深防御：每一层都假设上一层可能被攻破。
七、我的看法
我倾向于把这件事看成两个层面：
短期：升内核、重启，桌面用户 5 分钟搞定，服务器优先级看场景。
长期：这是又一次提醒——"long-term LTS"≠"long-term safe"。一个 2017 年合入的优化提交，在 2017 年的 commit review 中过了所有人的眼，但本质漏洞跨了 9 年没被发现。这背后的原因：
- • 加密子系统的 corner case 测试覆盖度不够——in-place 优化遇到 page cache 这种 edge case 没人想到
- • 静态分析工具对内核的能力有限——这种逻辑漏洞不是 buffer overflow 那种好查的模式
- • AI 代码审计工具开始派上用场——这次发现的是 Theori 的 Xint Code（他们家的 AI 代码审计工具）做的系统性扫描
Xint Code 的发现路径很有意思：他们用 AI 工具系统性扫描内核加密子系统，找到了人审 9 年没发现的逻辑漏洞。这反过来说明：AI 不只能写漏洞利用，也能在防御端帮忙找漏洞。这是 AI 在安全圈的真正价值——不是替代人，是把"人查不动的角落"翻一遍。
如果你管着任何 multi-tenant 的 Linux 主机，今晚就排个时间窗口升级内核。Copy Fail 的 PoC 已经公开，离野外利用只有时间问题。
参考来源：
- • Copy Fail — 732 Bytes to Root（copy.fail）[2]
数据截至：2026 年 5 月 1 日
欢迎大家进群沟通交流
微信：Tinker_AI
引用链接
[1] linux-distros@vs.openwall.org:mailto:linux-distros@vs.openwall.org[2]Copy Fail — 732 Bytes to Root（copy.fail）:https://copy.fail/[3]Lobsters 讨论帖:https://lobste.rs/s/eeifdc/copy_fail_732_bytes_root[4]Xint 官方技术 writeup:https://xint.io/blog/copy-fail-linux-distributions[5]The Register 报道:https://www.theregister.com/2026/04/30/linux_cryptographic_code_flaw/[6]BleepingComputer 报道:https://www.bleepingcomputer.com/news/security/new-linux-copy-fail-flaw-gives-hackers-root-on-major-distros/[7]The Hacker News 报道:https://thehackernews.com/2026/04/new-linux-copy-fail-vulnerability.html[8]oss-security 邮件列表披露:https://www.openwall.com/lists/oss-security/2026/04/29/23[9]Sysdig 复现分析: https://www.sysdig.com/blog/cve-2026-31431-copy-fail-linux-kernel-flaw-lets-local-users-gain-root-in-seconds
