一个 732 字节的 Python 脚本，研究方称可在多个主流 Linux 发行版上稳定拿到 root。

这个数字很抓眼球。但真正麻烦的不是脚本短，而是它打到的位置太底层：Linux 内核、AF_ALG、splice()、页缓存、setuid binary。

CVE-2026-31431 被命名为 Copy Fail。它不是远程漏洞，不会从公网凭空钻进机器。它需要一个本地代码执行落点：普通账户、容器里的代码、CI 里跑起来的恶意 PR，或者 Web RCE 之后拿到的低权限 shell。

问题也在这里。今天很多基础设施本来就在替别人运行代码。

它到底能做什么

Copy Fail 来自 Linux 内核 crypto/AF_ALG 路径里的逻辑缺陷。研究方描述的关键组合是 AF_ALG 与 splice()。

结果是，本地非特权用户可以对页缓存产生 4 字节可控写。再借由 setuid binary，这 4 字节足够把普通用户抬到 root。

这里要压住一个边界：这不是“远程直接拿 root”。它是权限放大器。攻击者必须先能在目标环境里跑代码。

问题关键信息对防守方的含义
漏洞能力本地非特权触发，改写页缓存，进一步提权重点看谁能在机器上执行代码
技术锚点AF_ALG、splice()、页缓存 4 字节可控写、setuid binary打在内核与文件执行路径交界处
影响范围研究方称影响 2017 年以来大量主流发行版内核，并验证 Ubuntu、Amazon Linux、RHEL、SUSE 等不能按发行版名称粗判，要看内核与补丁状态
修复方向更新包含 mainline commit a664bf3d603d 的内核多租户与执行不可信代码的环境应优先排期
临时缓解禁用 algif_aead，或用 seccomp 阻断 AF_ALG适合补丁窗口期降风险

它和 Dirty Pipe、Dirty Cow 属于同一个让安全团队头疼的家族：页缓存被破坏，磁盘文件不一定落盘改变，但内核执行路径已经读到了被污染的内容。

差别在于，研究方强调 Copy Fail 无 race，不需要抢时间窗口；也不依赖特定发行版偏移，迁移性更强。

这才是它不能被一句“又一个 Linux LPE”带过的原因。Linux 本地提权漏洞不少，但“无需竞争、跨发行版、页缓存破坏、可作为容器逃逸原语”叠在一起，并不常见。

谁最该紧张

风险不该平均摊给每台 Linux 机器。

单用户桌面、单租户服务器当然要修。但在这些环境里，它更像后渗透阶段的升级工具：攻击者已经能跑代码，再往 root 走一步。

真正压力在共享内核场景。

场景为什么风险更高现在该做什么
多租户 Linux 主机多个用户共享同一内核，普通用户落点可能变 root优先确认内核补丁或隔离策略
Kubernetes / 容器集群容器共享宿主机内核，边界依赖内核正确性不可信 workload 先收紧 syscall 面
CI runner / 构建农场主动执行外部代码、PR 代码、依赖脚本暂缓把不可信任务放进高权限共享 runner
自托管构建环境很多团队隔离弱于公有云托管环境检查 runner 权限、复用策略和补丁窗口
运行用户代码的云服务Notebook、沙箱、serverless、agent 环境给租户代码落点将内核更新列入高优先级变更

我更在意 CI 和容器。

很多团队说“不执行不可信代码”，流水线却每天拉依赖、跑测试、构建镜像、处理外部贡献。供应链安全不只看包管理器里有没有恶意库，还要看恶意代码一旦跑起来，底层环境能不能关住它。

容器也是同一笔账。容器隔离长期依赖一个前提：大家共享内核，但内核足够可靠。这个前提不是错，只是成本被藏起来了。

“天下熙熙，皆为利来。”云平台、CI 服务、容器编排押注共享内核，因为它便宜、快、密度高。Copy Fail 这种漏洞提醒的是另一面：省下的隔离成本，会以补丁压力、应急窗口和租户边界风险的形式回来。

最相关的两类人，动作应该很具体。

云平台和 Kubernetes 运维负责人，不该只等发行版大版本升级。要核对当前内核包是否已回补相关修复，确认不可信 workload 是否还能创建 AF_ALG socket。

CI/CD 负责人也要调整策略。共享 runner 上跑外部 PR、第三方构建脚本和未审计依赖时，临时降权、隔离 runner、缩短复用周期，比单纯写一条“禁止恶意代码”有用得多。

接下来该看什么

别被“732 bytes”“100% reliable”“every distro”这类词带着跑。

安全研究需要传播，漏洞命名也需要记忆点。但防守方不能把营销表达当成资产清单。

更稳的说法是：在研究方验证和声明范围内，Copy Fail 表现出较高稳定性和可移植性。你的环境是否中招，要看内核版本、发行版是否 backport、模块配置、seccomp 策略，以及 setuid binary 暴露情况。

接下来最该看四件事：

  • 发行版安全公告是否已经给出修复包，尤其是企业版内核的 backport 状态。
  • 当前内核是否包含 mainline commit a664bf3d603d 或等价回补。
  • algif_aead 是否可用，不可信 workload 是否能访问 AF_ALG。
  • CI runner、容器节点、多租户主机是否存在长期复用和高权限执行链。

短期处置也不复杂。

能更新内核，就尽快更新到包含相关修复的版本。补丁窗口没到，评估禁用 algif_aead。对不可信 workload，用 seccomp 收紧 AF_ALG 相关能力。

不要在生产环境里复现 PoC。也不要把“验证漏洞”变成新的攻击面。对多数团队来说，确认补丁状态和收紧执行边界，比追着复现细节更有价值。

Copy Fail 照出来的是一条老线：我们把越来越多不可信代码塞进同一个共享内核里，然后希望边界永远干净。

技术上可以这么做。商业上也划算。安全上，这笔账从来没有消失。