摘要
我们通过将 Copy Fail（CVE‑2026‑31431）视为舰队级紧急事件，得以抢占先机：数小时内关闭了整个基础设施中易受攻击的加密套接字接口，并在内核补丁稳定适用于我们的 AI 工作负载后立即部署。在上游修复广泛可用之前，我们依赖一项有针对性的内核加固措施：卸载易受攻击的模块并将其从模块路径中移除，以防止其被静默重新启用。
用一段话概括 Copy Fail
Copy Fail（CVE‑2026‑31431）是 Linux 内核加密子系统中 algif_aead AF_ALG 接口的一个逻辑错误，该接口用于 AEAD 操作。它允许任何无特权的本地用户向系统上任何可读文件的页缓存中写入精确的 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 节点）的非生产集群中，分阶段部署打了补丁的内核。
- 运行加速浸泡测试，以验证性能、GPU 驱动兼容性以及在实际推理和训练负载下的稳定性。
- 按区域和环境逐步推出打了补丁的内核，从共享较少的集群开始，随着遥测数据保持干净，逐步推向多租户密集的集群。
即使在打补丁之后，我们也会在那些没有明确需求的环境中保持禁用 algif_aead
。狭窄、专业的内核接口一旦出现问题，可能会产生生态系统范围的破坏半径；如果我们能在没有它们的情况下安全运行，我们就会这样做。
与此同时，我们的检测团队在遥测中增加了 Copy Fail 感知信号：
- 针对意外使用 AF_ALG 或在不应发生的内核模块加载的节点上的告警。
- 对特权二进制文件的行为监控，即使在磁盘映像保持不变的情况下，也能寻找异常。
运行安全 AI 平台的经验教训
Copy Fail 很好地说明了小型内核漏洞如何在 AI 基础设施中产生巨大影响：
- 共享内核和密集的多租户将局部漏洞放大为跨租户风险。
- 页面缓存技巧可以绕过传统的基于文件完整性的防御。
- “没人使用”的狭窄接口可能突然成为主要攻击面。
我们在 Together AI 的收获是继续收紧内核暴露模型：小众接口默认关闭，出现问题时快速进行全舰队切换，以及一个验证管道来证明这些决策与高性能 AI 工作负载兼容。