内核 TCP 洞 CVE-2026-98432 评级 9.8 与 5.9 发行版补丁进度不一

这两天在给几台 Linux 排十月的补丁，翻到这条的时候先愣了一下：同一个洞，内核自己的 CVE 组给 9.8，红帽的公开 CVE 页给 5.9 并标 Moderate。差 3.9 分，不是四舍五入的差别。我把各家跟踪页挨个看了一遍，顺手把能核的时间点对齐。



CVE-2026-98432，IPv4 TCP 建连路径上的释放后重用。位置在 tcp_v4_syn_recv_sock()：内核把半连接请求里存着的 IP options 交给新建的子 socket 时，交的是原来那块内存，不是副本。而处理待处理请求的路径没有持有 listener 锁，另一颗 CPU 完全可能在为同一个请求回 SYNACK（tcp_v4_send_synack() 走到 ip_options_build()）时还在读这块内存。子 socket 被销毁时用的是普通 kfree()，没有 RCU 宽限期，读的一方就直接踩到已释放内存。

同一个补丁还堵了第二条路径：TCP request socket 迁移，也就是 net.ipv4.tcp_migrate_req=1 或者挂了 BPF reuseport 程序的情况。IPv6 主路径不受影响，因为那边是把 options 复制走的。

修复是把释放改成 kfree_rcu()，等读的人走完再放。commit e3f33b0a1d89，作者 Eric Dumazet，报告者记的是 Anthropic 的 Xinyang Ge。

影响范围从 Linux 4.4 开始，所以几乎所有还在维护的发行版内核都带着这段代码。上游修复落在 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10 和 7.3。

时间线我按各家公告对齐过：10-02 修复写成，10-06 提交；10-15 内核 CVE 组发布 CVE 记录；10-16 Oracle 放出 UEK 修复包；10-24 内核 CVE 组把评分补成 9.8，同一天 Amazon 发了 kernel6.18；10-27 Anthropic 公开说它的模型写出了可用的利用；10-29 SUSE 发两份内核公告、Amazon 补 kernel6.12，红帽把修复标为延期，Ubuntu 仍在进行中。

评分为什么差这么远。内核 CVE 组的 9.8 建立在一个假设上：攻击者发一个带 IPv4 Record Route 或 Timestamp 选项的 SYN，然后重传命中这个 race，两侧都由攻击者驱动，所以攻击复杂度按低算。

红帽公开 CVE 页是 5.9、Moderate，理由是这个 race 难赢，最坏结果是内核崩溃，并且写明"没有演示出机密性或完整性影响"。但红帽 10-29 更新的机器可读 VEX 文件里，同一条给的是 8.1、Important。Cyber Kendra 说它没法独立确认这次 VEX 变更。这两个数我并列放着，不做合并，也不替红帽解释哪个算数——要判断就去看红帽自己的公告页当前显示什么。

其他家：Oracle 8.1、SUSE 8.1，都是 Important；Amazon 7.0；Ubuntu 直接沿用内核组的 9.8，优先级标 High。NVD 自己没出评分。

然后说 Anthropic 那篇。10-27 发的，说模型在"初步提示"之后写出了利用，针对的是带 MPTCP listener 的 Linux 服务器，远程、无凭据、拿到 root。两阶段：先用 race 让内核多回一段内存，从中拿到内核指针破 KASLR；再用同一个洞溢出缓冲区、覆盖一个回调指针，指向已经放进内核内存的载荷，内核一调用就以 root 执行命令。

有个细节值得记：输掉 race 只让那一次连接失败，不会把机器搞崩，所以可以一直重试。它自己测的时候，泄露内核地址花了 48 分钟，再花 5 分钟拿到命令执行。利用代码没公开，测的内核版本和配置也没说。

得说清楚一点：CVE 记录和内核的修复提交里都没提 MPTCP，MPTCP 这个条件是 Anthropic 那篇带出来的。没跑 MPTCP listener 的服务器能不能用同样的路子打，Anthropic 没说。

MPTCP 为什么不算小众。它在 Linux 上是按需开启的，应用建 socket 时得主动要，听起来很窄。但 Go 1.24 之后，Go 程序在 Linux 上的监听 socket 默认就开 MPTCP，Go 安全团队 10-29 专门发了提醒。反代、API 网关、exporter、控制面 agent，很多是 Go 写的。

两边都有保留：Go 团队说这个洞本身不限于 MPTCP，红帽说任何可达的 TCP 服务都可能是触发点；关掉 MPTCP 只是砍掉已经被演示的那条路径，不是修洞。Go 团队也不建议改默认值，理由是按程序逐个关太脆，漏一个监听就白搭。

补丁状态这块差别很大，按 10 月 30 日能查到的：

Debian 两个分支都有包，bookworm 是 6.1.190-1（DLA-4841-1），trixie 是 6.12.113-1（DSA-6568-1）。Oracle Linux 的 UEK 10-16 就发了，ELSA-2026-500397、500398、500399 三条。openSUSE Leap 16.0 和 SUSE Linux Micro 6.2 是 kernel-default 6.12.0-160000.40.1 或更高。SLES 15 SP4 到 SP6 LTSS、SLES 16.0 这批在测；SLES 15 SP7 还在做。

Amazon Linux 2023 的 kernel6.18 包 10-24 修好，kernel6.12 是 10-29 才在公告里写修好，但它自己的 CVE 页还写着 pending——自家页面不同步这种事常见，以公告为准，但也别当它已经全绿。

Ubuntu 22.04 到 26.10 全部列在进行中，没有包；16.04、18.04、20.04 直接标受影响、无修复。红帽 RHEL 8、9、10 和 OpenShift 4 是延期到后续更新，目前没有包。红帽把 RHEL 7 标为不受影响，理由是它的内核从来没有这段代码，有一条来源同时把 RHEL 6 也列进去。

在野利用这块：截至 10-29，没有任何厂商、CERT 或内核 CVE 组报告在野利用，CISA KEV 目录（版本 2026.10.28）里也没有它。

我会怎么排。先 uname -r 把实际内核版本对到发行版公告上看，别只看大版本号。Debian、Oracle、openSUSE 有包的直接上，内核更新必须重启才算生效。

Ubuntu 和 RHEL 现在没包，只能先收暴露面：对外只留必要的端口，管理面和内部服务不要直接挂公网。Shield53 的建议里给了临时把 net.mptcp.enabled 设 0 的做法，我没在受影响的内核上跑过这条，只当参考——而且按 Go 团队的说法，这挡的是 MPTCP 那条路，不是洞本身。

优先级我按这个排：跑 Go 1.24 以上版本又对外监听的服务排前面，其次是容器宿主机（共享宿主机内核），最后才是纯内网机器。

来源：
1. 内核 CVE 记录 CVE-2026-98432，2026-10-15 发布，10-24 补 9.8 分
2. Ubuntu CVE 跟踪页 https://ubuntu.com/security/CVE-2026-98432
3. Red Hat CVE 页与 10-29 更新的 VEX 数据
4. Debian 安全跟踪页 DSA-6568-1、DLA-4841-1、DLA-4850-1
5. Oracle ELSA-2026-500397/500398/500399；SUSE-SU-2026:24386-1；Amazon ALAS2023-2026-3251、ALAS2023-2026-3335
6. The Hacker News，Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions，2026-10-29
7. Cyber Kendra，Critical Linux Kernel TCP Flaw CVE-2026-98432 Still Unpatched on Ubuntu and RHEL，2026-10-29
https://www.cyberkendra.com/2026/10/cve-2026-98432-linux-kernel-tcp-flaw-ubuntu-rhel.html
8. Prime Reports 发行版状态表，2026-10-29
https://primereports.org/linux-kernel-tcp-flaw-with-9-8-cvss-score-affects-ubuntu-red-hat-and-other-distributions
9. Anthropic 2026-10-27 研究帖（利用描述，未公开代码）
10. CISA KEV 目录，版本 2026.10.28

交叉核对说明：受影响起始版本 4.4、上游修复版本号、commit e3f33b0a1d89、报告者、时间线，四家独立来源逐项一致；评分分歧处各家写法不同，正文已并列，未做统一。

HKTULU
2026-10-30