Linux TCP 漏洞 CVE-2026-98432：MPTCP 之外还要检查什么

先分清漏洞本身和一次利用演示

Linux 内核在处理 IPv4 TCP 连接时存在一处释放后使用漏洞，编号 CVE-2026-98432。它发生在内核处理连接请求的过程中，不需要先进入某个网站的管理后台。是否受到影响，取决于正在运行的内核代码是否包含修复，以及相关网络路径是否可达。

10 月 27 日，Anthropic 描述了一次研究环境中的远程利用：针对存在 MPTCP 监听的 Linux 服务器，构造数据包后实现 root 命令执行。10 月 30 日，Red Hat 发布安全通告，提醒用户关注其受影响产品的内核修复与缓解。研究演示说明风险可以很严重，但不等于每台 Linux 服务器都已经被攻破，也不能把一次实验当成已确认的在野攻击规模。

一个连接还没完成，为什么内核会读到失效的数据

客户端建立 TCP 连接时，服务器需要暂时保存连接请求的状态。IPv4 报文头还可以携带 IP 选项，内核处理相关请求时也会保存这些选项，以便继续构造回应。完成握手后，新连接会接管部分状态。

麻烦出在并发时机：一个执行路径正在处理连接并释放相关选项，另一个执行路径可能同时处理重传请求并读取它们。若内存已经释放但读取还在继续，读取方拿到的内容就不再可靠，这就是释放后使用。它可能导致内核崩溃或内存破坏；能否进一步变成可控的命令执行，还需要满足更具体的利用条件。

上游修复的方向，是让仍在读取这些选项的路径结束后再回收相关内存，而不是在另一个处理过程可能还要使用时立即释放。对运维人员来说，真正需要确认的是发行版提供的运行内核是否包含相应修复，而不是只看应用版本。

MPTCP 不是漏洞的开关

MPTCP 允许一个连接使用多个网络路径。Anthropic 描述的远程 root 演示依赖目标存在 MPTCP 监听；但 Go 项目安全讨论指出，底层释放后使用位于普通 IPv4 TCP 连接处理逻辑，并不专属于 MPTCP。没有 MPTCP 监听，不足以证明内核中的缺陷不存在。

Go 项目维护者还说明，从 Go 1.24 起，net 包会在支持的 Linux 环境中默认启用 MPTCP 监听。实际是否生效，还要看应用、内核和运行配置；不能仅凭“我们主要跑 PHP”推断机器上没有其他 Go 服务，也不能据此推断一定存在可利用的监听。

项目讨论给出的 GODEBUG=multipathtcp=0 可用于改变 Go 程序的默认行为，但它针对该程序，不会修复内核，也不能保证防住其他可能的利用路径。调整前要考虑服务重启及业务对 MPTCP 的依赖。

补丁看发行版，别只比较 uname

先在服务器上确认正在运行的内核，再查这台机器所属发行版针对 CVE-2026-98432 的安全公告和软件包。uname -r 给出当前运行版本，但发行版常把修复回移到自己的内核包：版本号看起来较旧，不一定没有补丁；安装了新包，也不代表机器已经运行新内核。

下面两条只用于查看系统和运行版本，不会安装软件或重启。查询后应以发行版或云厂商提供的受影响范围、包版本及修复说明为准；如果没有对应公告，状态应记为待确认。

uname -r
cat /etc/os-release

补丁没到时，临时措施能做什么

Red Hat 给出了过滤带 IPv4 选项的 TCP 入站包作为降低暴露的临时措施，并提醒它不能完全阻止所有路径，也不能代替打补丁。IPv4 报文头选项与常见的 TCP 头选项是不同字段，不能把禁用一切 TCP 选项当成同一件事。

网络规则可能影响现有流量，也可能无法覆盖所有转发或容器路径。应先结合发行版建议、真实网络拓扑、业务兼容性和回滚方式评估，再在合适的环境验证；不要直接把互联网上的规则或脚本套到共享生产服务器。

修复包可用时，按发行版流程安排内核更新，并确认系统实际启动到已修复内核；若使用受支持的实时补丁，也要核实该补丁确实覆盖此 CVE。重启和防火墙调整影响整台主机，涉及其他业务时应先协调维护窗口。