Linux TCP 释放后重用漏洞：打补丁还是先缓解

你的内核在 TCP 握手路径上存在可被远程触发的释放后重用漏洞，发行版还没有推送修复，而且已经有人演示了可用的 root 提权利用。那么接下来怎么办：干等，还是马上在防火墙上丢包？这个编号为 CVE-2026-98432 的 Linux TCP 释放后重用漏洞，是安全运维里最古老的那个选择题——打补丁还是先缓解——的一个很好的案例。坦白说，这两个选项根本不对等：只有一个真正解决了问题。

这种情况我两边都经历过。我曾因为缓解措施在纸面上看起来够用，而推迟了紧急内核升级；也眼看着一条“临时”防火墙规则在生产环境里悄悄烂了八个月，所有人都忘了它是在给哪个 CVE 打掩护。这个漏洞很适合拿来好好聊聊：什么情况下哪种方案更占优，因为这里的权衡异常清晰。

这个漏洞到底是什么

机制本身很重要，因为它决定了缓解措施能做什么、不能做什么。服务器接受一个 IPv4 TCP 连接时，内核会用一个轻量的请求套接字（request socket）记录半开的握手状态，等握手完成后再将其升级为完整套接字。如果对端的 IPv4 报文头带有选项，内核会把这些选项保存下来，以便在回复中原样带回。问题出在这里：内核把这些保存的选项交给新连接时没有做复制，而是立即释放了它们——与此同时，另一个 CPU 可能还在读取这些数据来构造握手回复。这就是释放后重用，而且任何远程、未认证的对端都能触发，甚至在你的应用代码执行任何一行之前就已经发生了。

上游修复来自 Eric Dumazet，只有四行：两处普通的 kfree() 调用被替换为 kfree_rcu()，后者会推迟释放，直到所有读者都用完这块内存。这正是这类漏洞的经典内核修法——RCU 读者会持有你看不见的引用，所以要等宽限期（grace period）过去之后再回收。内核自己的 CNA 给出的评分是 CVSS 9.8。Red Hat 最初评为 8.1，然后在 10 月 30 日上调到 9.8（Critical），理由是该漏洞不需要任何网络前置条件。

有两个细节改变了风险评估。第一，竞争条件失败得很“温和”：一次失败的尝试只会让握手失败，不会让机器 panic，因此攻击者可以无限次重试。第二，Anthropic 演示的利用路径针对的是带有多路径 TCP（MPTCP）监听器的主机；而据 Go 安全团队的说法，自 Go 1.24 起，只要内核允许，Linux 上的 Go 程序默认就会开启 MPTCP 监听器。检查一下你的机器群：

ss -Mlnp                 # MPTCP listeners and their owning processes
sysctl net.mptcp.enabled # 1 means apps may open MPTCP sockets

ss -M 输出为空，说明没有 MPTCP 监听器。但别因此就放松——Go 团队明确指出，底层漏洞并不是 MPTCP 特有的。它是握手处理代码中的通用释放后重用问题；MPTCP 只是目前有人端到端验证过的路径而已。

补丁路径：修复内核、重启、完事

打补丁这件事说起来很无聊，因为它是唯一能真正消除漏洞、而不是把漏洞换个形式藏起来的方案。10 月 11 日和 15 日，上游为所有仍在维护的稳定分支发布了修复版本。而这个漏洞可以追溯到 Linux 4.4，这意味着大量长尾系统都受影响，其中一些内核老到上游已经不再维护。

麻烦在于重启。内核更新在机器重启进入新内核之前不会生效，而真正的运维成本就藏在重启里：要排空 Kubernetes 节点、演练故障切换、还有那个谁都不想在工作时间重启的数据库主节点。所以“直接打补丁”作为建议永远是对的，却永远不够。你需要一份发布计划：先金丝雀主机，再无状态服务层，最后是有状态服务并安排维护窗口。如果你之前经历过全网紧急更换内核，就知道这套流程。处理得好的团队，都是在没有火烧眉毛的时候就演练过节点排空；你在平静的周二建立起来的防御性工程习惯，才会在遇到 9.8 分的漏洞时派上用场。

有个坑值得点出来：dpkg -l 或 rpm -q kernel 显示已安装修复版本，并不代表什么，如果正在运行的内核还是旧的。uname -r 才能告诉你实际在跑什么。在 RHEL 系发行版上，needs-restarting -r 会明确告诉你是否有待生效的重启。我审过不少事后复盘报告，里面的“已修复”机器群，其实是一大堆“已安装但没在运行”的内核。要以你所用发行版的安全公告为准去核对运行版本，而不是上游版本号——发行版内核会在自己的版本体系下带上回移补丁（backport）。

缓解路径：丢弃 IPv4 选项，禁用 MPTCP

目前公布的临时缓解措施，是一条 nftables 规则：丢弃携带 IP 选项的入站 IPv4 TCP 报文，因为这正是触发漏洞路径的条件。如果你不使用 MPTCP，还可以通过禁用它（sysctl -w net.mptcp.enabled=0）作为补充。两者都很快，不需要重启，并且用配置管理工具半天就能铺开。这就是它的吸引力所在。

接下来这部分应该能让你的热情降降温：Red Hat 自己的公告写道，其规则“降低了该漏洞的暴露面，但无法完全防止”。这句话请多读两遍。缓解措施是缩小攻击面，而不是关闭它。携带 IP 选项的报文在正常流量中很少见，大多数中间设备本来就会丢弃它们，这也是为什么公网上的利用被认为不太可能——但“很少”和“不可能”是两码事。而且这个漏洞位于通用的握手代码里，并不只是某人碰巧测试过的那条选项路径。

还有个更隐蔽的代价：缓解措施会制造一种虚假的“已解决”感。工单被标记为“差不多完成”，修补工作的紧迫感就此消散，六周之后，你还在用一个带漏洞的内核，躲在包过滤器后面，而当初为什么要这么做的记忆早已淡去。我在PHP 高危 CVE 处置窗口那篇文章里写过类似的模式：那些直接把有漏洞的东西下线的团队，比那些堆叠各种巧妙过滤规则的团队结果更好。道理一样，只是技术栈不同。

打补丁还是先缓解：各自何时胜出

这是我多年在压力下做这个决定后，给出的诚实评分表。

• 你的发行版已有修复内核。打补丁直接胜出。Debian、SUSE Enterprise、Oracle UEK 和 Amazon Linux 都已经发布了修复。没有比上游四行修复更巧妙的缓解方案。安排好重启，分批滚动升级，然后继续前进。
• 还没有修复内核，而且风险真实存在。立即缓解，这正是缓解措施存在的意义。10 月底时，Ubuntu 和 RHEL 仍然处于“Vulnerable”/受影响状态。如果你的服务面向公网且开启了 MPTCP 监听器，那就今天就丢弃带 IP 选项的报文并禁用 MPTCP，同时像跟踪一个阻塞发布的依赖那样持续跟进修复内核。
• 面向公网，但位于托管的前端之后。你的紧迫度可以降低。AWS 的建议是：流量经由其负载均衡器、CloudFront 或 API Gateway 转发，不会以原始的不可信 TCP 形式到达你的实例，这个判断是靠谱的。仍然建议执行缓解（成本很低），然后在常规周期内打补丁，而不是走紧急流程。
• 单核或单队列系统。优先级较低。竞争条件需要多个 CPU 并发处理报文。嵌入式设备和小型虚拟机会获得一些喘息空间——但它们往往也是没人会重启的机器，所以别让“低优先级”变成“永远不处理”。
• 已停止支持的内核（上游 5.10 之前）。缓解是你唯一不依赖上游的选择。这是缓解措施真正占优的场景，因为另一条路是等厂商的回移补丁，而它可能永远不会来。这同时也是一个明确信号：问题在于这台机器本身，真正的解决办法是更换它。

真正的问题是发行版的时间差

真正该让你不安的，不是这个漏洞本身——四行的释放后重用修复每个月都会进入稳定内核。而是全球最大的两家服务器发行版 Ubuntu 和 RHEL，在上游发布超过两周后仍然没有推送修复；与此同时，Amazon Linux 已经为其所有内核打好补丁，社区重建版 AlmaLinux 则在测试版中抢先于上游推出了修复内核。Hacker News 的评论区也注意到了这一点，而他们有理由生气：这些恰恰是最大力宣传自己服务器就绪程度的发行版。

对一线从业者来说，结论很朴实：你的暴露窗口是由厂商的回移补丁流水线决定的，而不是由上游决定。由此可以得出两件事。第一，记下你所用发行版的安全公告地址，并真的去盯着它们——这个 CVE 在 NVD 上长时间停留在“Received”状态、没有任何分析，而内核 CNA、Red Hat 和各发行版其实早已有了详细页面。第二，把发行版的响应速度当作选型标准之一。Amazon Linux 刚刚展示了比两家老牌厂商明显更快的内核修复流水线。这在营销材料里毫无分量，但在万圣节周末一个 9.8 分的漏洞突然出现时，它就很重要了。

AI 写出的利用代码改变了时间表

披露材料中最有分量的一句话，很容易被略过：Anthropic 报告称，其 Claude 模型在初始提示之后，生成了一个可用的远程 root 利用，从内核指针泄漏到拿到 root shell，只用了不到一小时的机器时间。他们没有公开这份利用代码，而 Hacker News 上的怀疑者对“相信我，兄弟”式的说法颇有微词。这种质疑有道理。但即便打了折扣，趋势依然很明显：从“补丁进入稳定分支”到“可用利用出现”之间的时间正在急剧缩短，因为利用开发的瓶颈从来不是漏洞本身，而是那个能读懂补丁差异并完成堆布局（heap grooming）的人。

这就压缩了“打补丁还是先缓解”的决策窗口。当利用开发需要数周时，“先缓解，下个维护窗口再打补丁”还站得住脚。而当模型能根据一个公开提交在一夜之间炮制出概念验证（PoC）时，你的缓解阶段就得以小时计，打补丁阶段则要以天计。四行修复是公开的，任何人都能研究它。所以，请假设利用代码也已经存在。

我的建议

打补丁。缓解只能作为过渡手段，而且要给这个过渡手段设定失效日期。具体来说：如果你的发行版已有修复内核，现在就开始滚动升级，并且每次重启后都用 uname -r 核对版本。如果你用的是 Ubuntu 或 RHEL，今天就部署丢弃 IP 选项的规则并禁用 MPTCP，然后把缺失的内核修复当作一个阻塞性依赖来管理——每天检查安全公告，而不是每周检查。优先处理面向公网且开启了 MPTCP 监听器的服务，然后是其他所有接受入站 TCP 的服务，而这几乎涵盖了全部。容器也救不了你：它们共享宿主机内核，所以要给节点打补丁。

更深层的教训，是这个漏洞每隔几年换个新 CVE 编号就会再教一次：缓解措施只能争取时间，只有补丁才能堵住漏洞，而缓解争取到的时间正变得越来越短。在真正需要之前，就把快速、安全地滚动升级内核的能力练出来吧——因为下一个四行修复，此刻可能已经躺在别人的队列里了。