Linux 内核 MPTCP 漏洞 CVE-2026-98432：不动包，先关一个用不上的协议

最近 Linux 内核曝出一个 TCP 相关漏洞，编号 CVE-2026-98432。内核团队给出的 CVSS 评分高达 9.8 分，厂商评分则在 5.9 至 8.1 分之间。这个分差本身就说明一个问题：漏洞的危害要看触发条件，而不是只看分数。

本文只讲通用处置方法，不涉及任何具体机器、地址和账号。

一、先看触发条件，别被分数吓住

这个漏洞的本质，是建立新的 IPv4 TCP 连接的代码里存在竞态条件，可能导致内核读取已释放的内存，也就是释放后使用（use-after-free）。

关键在触发条件：攻击者要利用它，需要目标服务器上启用了多路径 TCP（MPTCP）监听器。没有 MPTCP 监听口的机器，并不在这个利用链的直接命中范围内。也就是说，第一步不是马上升级，而是先查自己有没有命中条件。

二、第一步：查有没有 MPTCP 监听口

在服务器上用系统自带的连接查看工具，筛选 MPTCP 类型的监听连接：

• 如果结果是空，说明当前没有 MPTCP 监听口，这一步就先不用慌，继续往下做预防性关闭即可。
• 如果结果里有监听口，记下对应的服务和端口，再往下处理。

注意一个容易误判的点：普通 TCP 监听口不算命中条件。只有明确显示为 MPTCP 的监听，才算命中。

三、第二步：把 MPTCP 开关关掉，并写进配置持久化

如果机器平时根本用不上 MPTCP，最稳妥的缓解办法就是把它关掉：

1. 把内核参数 net.mptcp.enabled 设为 0。
2. 把这个设置写进系统启动时自动加载的配置文件里，只改一次、重启后也不会变回来。
3. 重启相关服务，让已经存在的 MPTCP 监听清理掉。

做完之后再查一次，确认 MPTCP 监听已经归零，而普通 TCP 服务口还在正常监听。开关关掉之后，普通 TCP 流量不受影响，走的还是原来的 TCP 路径。

四、为什么单网卡、单 IP 的机器基本无感知

MPTCP 的本意，是让一条连接同时走多条路径，比如多网卡、多 IP 的场景。如果机器只有一块网卡、一个出口 IP，平时根本走不到多路径，关掉 MPTCP 之后，日常应用基本感觉不到变化。

另外，UDP 协议也不受这次关闭的影响。MPTCP 是 TCP 的扩展，关掉它不会动 UDP 服务的监听和流量。

五、补丁现状：升级要等补丁，不能只看分数就动手

截至本文所依据的公开信息，Debian、Oracle Linux、SUSE 和 Amazon Linux 已经发布了部分修复包，Ubuntu 和 RHEL 的修复包当时尚未发布。

所以补丁这条线要分两步走：

1. 先做上面这步“关掉用不上的协议”，这是不动包就能做的缓解。
2. 等所用发行版正式发布修复包之后，再按正常流程升级内核并重启。内核升级涉及重启，生产机器一定要提前安排窗口，不能因为分数高就半夜直接动手。

六、一个简单的处置顺序

1. 查 MPTCP 监听，有没有命中条件先分清。
2. 用不上的 MPTCP，先关掉并持久化。
3. 重启服务，复查 MPTCP 监听为零、普通 TCP 口还在。
4. 关注所用发行版的公告，等补丁出了再升级内核并重启。

先分清条件、再做缓解、最后等补丁，这样的顺序比一上来就全量升级要稳，也更适合不想动包、不想半夜重启的机器。