摘要
我们把 Copy Fail（CVE‑2026‑31431）当作整个集群层面的紧急事件来处理，在数小时内关闭了全部基础设施上存在漏洞的加密套接字接口，并在内核补丁在我们的 AI 工作负载中稳定后分批上线，从而抢在了漏洞被利用之前。在上游修复尚未广泛可用时，我们采取了一项有针对性的内核加固措施：卸载存在漏洞的模块，并将其从模块路径中移除，使其无法被悄悄重新启用。
一段话讲清 Copy Fail
Copy Fail（CVE‑2026‑31431）是 Linux 内核加密子系统中的一个逻辑漏洞，位于用于 AEAD 操作的 algif_aead AF_ALG 接口。任何无特权的本地用户都可以借此对系统上任意可读文件的页缓存（page cache）执行精确的 4 字节写入。在实践中，公开的利用代码会在内存中改写共享的 setuid 二进制文件的几个字节，借此在主流 Linux 发行版上提权到 root。磁盘上的文件始终没有变化，该页也不会被标记为脏页，这意味着传统的文件完整性检查即使在被篡改的二进制文件运行时也发现不了攻击。
为什么这对 AI 基础设施很重要
在开发者的笔记本上，Copy Fail 只是一个本地提权漏洞。但在现代 AI 平台中，“本地”通常意味着 CI 任务、多租户 GPU 节点、临时的研究环境，或是自带依赖的第三方工作负载。
从云和 AI 的角度看，风险如下：
- 在能访问 AF_ALG 套接字的容器内发生的入侵，可以被转化为对底层宿主机的 root 权限。
- 由于页缓存是共享的，一个工作负载的写入可能会悄无声息地破坏同一节点上其他租户使用的二进制文件或库。
- 一旦宿主机被拿下 root，访问挂载的存储、控制平面和相邻工作负载就容易得多。
我们一直是在“容器不是安全边界”的假设下运行的。而在共享内核的多租户环境中，如果放任存在漏洞的接口暴露在外，Copy Fail 正是那种安静、确定性的攻击原语，足以瓦解仅剩的那点安全余量。
我们的即时响应：在所有环境中禁用 algif_aead
一旦出现可用的漏洞利用细节，我们就把精力集中在最直接的手段上：不再暴露存在漏洞的 AF_ALG 接口。
对 Together AI 的生产工作负载而言，推理和训练主机并不依赖用户态的 algif_aead 套接字。这让我们可以在整个集群范围内采取一个简单粗暴但安全的动作：
卸载 algif_aead 模块后，运行中的内核里存在漏洞的代码路径立即被关闭。把模块文件移出标准模块目录，则避免了系统服务或自动化脚本在日常运维中再次加载它。
这一做法有几个重要特点：
- 快速：无需重启，这对运行长时间 GPU 任务的场景很重要。
- 低风险：典型的服务器和 AI 工作负载并不直接依赖 AF_ALG AEAD 套接字，因此对运维的影响很小。
- 持久：即使主机重启后仍运行同一个有漏洞的内核，它启动后
algif_aead依然处于禁用状态。
我们把这项措施写成了配置管理中的幂等合规检查：只有模块已卸载且 .ko 文件已被隔离，主机才算健康。
安全地推出内核补丁
禁用 algif_aead 只是缓解措施，而不是最终状态。一旦厂商发布了 CVE‑2026‑31431 的补丁，我们将转入更传统的流程：
- 先在非生产集群中部署打过补丁的内核，这些集群要能模拟我们最重的 AI 工作负载，包括高密度的多租户 GPU 节点。
- 运行加速的浸泡测试（soak test），检验性能、GPU 驱动兼容性，以及真实推理和训练负载下的稳定性。
- 按地区和环境逐步推出打过补丁的内核，从共享程度较低的集群开始，在遥测数据保持正常的前提下，逐步推进到多租户程度高的集群。
即使打完补丁，我们仍会在没有明确需求的环境中保持 algif_aead 禁用。一旦出问题，狭窄而专门的内核接口可能造成波及整个生态的影响；只要能安全地不用它们，我们就不用。
与此同时，我们的检测团队在遥测中加入了针对 Copy Fail 的信号：
- 对本不应出现的节点上意外的 AF_ALG 使用或加密模块加载发出告警。
- 对特权二进制文件进行行为监控，即使磁盘上的镜像没有变化，也能发现异常。
运行安全 AI 平台的经验教训
Copy Fail 很好地说明了，小小的内核漏洞会对 AI 基础设施产生多大的影响：
- 共享内核和高密度多租户会把本地漏洞放大为跨租户风险。
- 页缓存技巧可以绕过基于文件完整性的传统防御。
- “没人用”的狭窄接口可能一夜之间成为主要攻击面。
Together AI 的心得是：持续收紧内核暴露面模型，即小众接口默认关闭，出问题时能在整个集群范围内快速切换开关，并有一条验证流水线来证明这些决策与高性能 AI 工作负载兼容。