Fly.io 因 Linux 内核漏洞紧急修复并重启全部服务器

Annie Ruygt 2026年10月16日，Fly.io 的一天和往常一样开始了（也就是说，我们只预期了中等程度的混乱）。到了当晚，为了应对一个 Linux 内核漏洞，我们已对整个机群完成打补丁和重启。完整 rollout 花了 10 个小时，但情感上的创伤仍在持续。

如果不先清楚理解这个漏洞本身，后面的内容就没太大意义，所以：Linux 内核 CVE 团队和 pwn.ai 在 15 日上午公布了 CVE-2026-99999。我们当晚得知此事，并开始着手缓解措施。

TCP 和 UDP 这类协议包含校验和，用于检测数据在互联网传输过程中是否损坏。计算校验和意味着要读取整条消息，在高速场景下这会累积成不小的开销。Linux 通过校验和卸载（checksum offload）来避免这一点：内核不立即计算校验和，而是存储元数据，指明校验和应该从哪里读取、写到哪里。如果最终不需要校验和，内核就完全不必花费 CPU 去计算。

比如发送到 localhost 时，或者网卡能够自行添加校验和时，就不需要。

校验和卸载对虚拟机也是同样的工作方式。虚拟网卡接受校验和元数据并传递给宿主机。在宿主机侧，数据包被当作任何其他卸载包处理，使用 guest 提供的元数据。

卸载代码中有用于拒绝错误元数据的检查。对于 IPv4，这些检查是错误的。要利用这一点，攻击者需要做三件事：将校验和指向另一个头部字段，挑选一条能产生他们想要的校验和的消息，并迫使宿主机在软件中计算校验和。pwn.ai 的帖子详细介绍了如何做到这一点。最终结果：宿主机收到数据包，解析它，决定发送到哪里，然后在错误的位置应用校验和。

攻击者现在控制了宿主机已经信任的 IPv4 头部中的两个字节。

根据 rollout 期间观察到的网络活动，我们认为客户数据实际暴露的可能性不大。理论上，在漏洞披露到我们最终重启之间，恶意应用有可能读取同一物理宿主机上其他应用的小块网络流量，但我们没有证据表明这确实发生过。

如果你在 10 月 15 日至 17 日期间运行在 Fly.io 上：该漏洞利用很难检测，因此出于谨慎，请轮换你在该时间段内通过 HTTP 或其他未加密协议发送的任何凭据。这包括通过你的 6PN 传输的未加密流量。

我们的工作是帮助你运行你那些了不起的东西，这就是为什么我们非常重视强硬件虚拟化。这是将工作负载彼此隔离的最可靠方式。guest 不应该能够在少数几条窄定义路径之外影响宿主机。像这样的漏洞会在上面打洞。在这个案例中，是两个洞。

第一个是防火墙绕过。针对源 IP 或目的 IP 的重写发生在宿主机已经应用路由和防火墙规则之后。上游修复现已到位。

第二个是越界读取。针对头部长度的重写会诱使宿主机将相邻内存当作数据包的一部分。将最小的 IPv4 头部重写为最大长度，会把 32 字节内存作为选项捕获到出站数据包上。那块内存可能包含宿主机数据包、内核数据结构，以及隔壁 VM 的数据包。仅来自相邻 VM 的泄露本身，就足以让人放下一切。

检测这类活动很难。防火墙绕过的数据包可以完全格式良好。越界读取的数据包在包含选项后很可能带有错误的头部校验和，但等你能看到这一点时，已经太晚了。我们研究过调整现有的 XDP 规则，但重写发生在它们运行之后。当然，我们可以禁用宿主机上的校验和卸载，但那需要重启。而如果我们要重启，我们就会重启到已打补丁的内核。

我们的每台宿主机重启大约需要 15 到 20 分钟（服务器硬件就是这么酷），在此期间其上运行的每个 Fly Machine 都会停机。我们的放置策略还会将 Machine 随机分散到宿主机上，因此我们一次只能重启一台宿主机，否则就会让某些不幸应用子集的每个 Machine 都宕机。

单 Machine 应用无论我们怎么做都会宕机。

所以，我们围绕 Managed Postgres 做了规划。我们将每个区域分成波次，确保没有哪个 MPG 集群的两个节点处于同一波次。即使 MPG 集群数量有限，我们最大的区域 iad 也需要 17 个波次。

当然，计算机的表现就像计算机。大多数宿主机在我们公布的预估时间内恢复了，但有些没有。少数重启后缺少必要软件，需要重装。其他的卡在 BIOS 中，而 gru 的一个四节点机箱在事件中途失去了电源供应，现场没有备件。那些宿主机上的 Machine 一直停机，直到我们在 20 日恢复它们。但最终，没有 Fly Machine 或客户数据丢失。

UTC 16:22，我们在状态页面上发布了紧急维护通知，并开始通知我们最大的客户。通知写的是“维护”，不是安全，也没有点名 CVE。大家毫不客气地告诉我们这让人无法接受，这完全合理。当天就来的“紧急维护”重启你的整个应用，看起来就像我们干了什么蠢事，正在疯狂打补丁却不告诉任何人原因。

我们自己感觉也不好受，但告诉互联网我们有漏洞（以及漏洞持续了多久）感觉是个明显更糟的主意。这种情况尤其棘手，因为该漏洞是连同如何利用它的详细说明一起披露的。

当时，我们认为最重要的是避免确认我们的宿主机现在有漏洞。我们无论如何能把沟通渠道做得更好吗？永远可以。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）