结论先摆出来：Linux 内核的 TCP 代码里有一处竞态，评了 9.8（内核自己的 CVE 团队给的），不用登录、远程就能让服务器以内核身份跑命令。到 10 月 29 号为止，Ubuntu 和 RHEL 都还没放出修好的内核。

编号 CVE-2026-98432。出问题的地方在内核建立新的 IPv4 TCP 连接那段代码里——两个时机没对齐，内核会去读一块已经释放掉的内存，也就是 use-after-free。这种 bug 本身不算稀奇，要命的是它落在连接建立路径上，还没认证就能碰到。

「能拿 root」这条，得点一句：10 月 27 号 Anthropic 说，他们的 AI 模型写出了一个利用，专打配了 multipath TCP（MPTCP）监听的服务，打进去就是不用凭据的远程 root 命令执行。这里有个细节容易看漏——CVE 记录和内核修复本身都没提 MPTCP，这个「得先有 MPTCP 监听」的前提，是从 Anthropic 那份利用里带出来的。换句话说，不是所有 Linux 服务器都躺枪：普通 nginx 那种监听走的还是普通 TCP，真配过 MPTCP 监听的才有这个面。

有意思的是分差。内核团队按 9.8 算，Red Hat、Amazon、Oracle、SUSE 四家给的是 5.9 到 8.1，同一个洞差出一个多档，多半就卡在「到底多少环境真会开出 MPTCP 监听」这个前提上。内核补丁里致谢的，是 Anthropic 的研究员 Xinyang Ge。

影响版本：配了 multipath TCP（MPTCP）监听、且没升到修复内核的 Linux。按各家评估，Ubuntu、RHEL 等在受影响范围内。

修复版本：暂无——截至 10 月 29 日，Ubuntu 和 RHEL 都还没发出修好的内核。各家在陆续出，装之前认准对应官方公告里的版本。

一条自查：先看内核 uname -r，再确认 MPTCP 到底开没开、有没有 MPTCP 监听——sysctl net.mptcp.enabled（回到 0 就是关着）。平时根本用不到 MPTCP 的，可以先把它关掉收窄口子：sysctl -w net.mptcp.enabled=0，写进 /etc/sysctl.d/ 持久化。真用得到 MPTCP 的，就盯紧各家内核更新，出来第一时间升。

补丁没来这几天的空窗最难受。这种「评分很高、补丁没有」的处境，我们前阵子刚在 LMCache 那个 9.8 分的洞 上碰过一回，处理思路一样：先把暴露面收回来，别干等补丁。内核升级终究要重启、要排窗口，而 MPTCP 用不上的人，一条 sysctl 就能先把风险压下去，不亏。

也别把这个洞想得太普遍。MPTCP 不是默认会去用的东西——多数机器上它压根没有监听。真正该紧张的，是那些特意开过多路径、跑在边缘或移动网络场景里的环境；偏偏这类机器，往往也不是随手能重启的，才最拖。

原始来源：The Hacker News《Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions》：https://thehackernews.com/2026/10/linux-kernel-tcp-flaw-with-98-cvss.html