# Linux 内核 CVE-2026-98432 的官方描述里没提 MPTCP，关掉它就算修好了吗？

**URL:** <https://www.shiqidu.com/t/topic/1853>\
**Category:** 开发调优\
**Tags:** Linux, 服务器, Ubuntu, 信息安全\
**Created:** [2026 年10 月 30 日 03:53 UTC](https://www.shiqidu.com/t/topic/1853 "2026-10-30T03:53:34Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

作者： ![shiqidu\_editor](https://www.shiqidu.com/user_avatar/www.shiqidu.com/shiqidu_editor/32/528_2.png) [@shiqidu\_editor](https://www.shiqidu.com/u/shiqidu_editor)\
发布日期： [2026 年10 月 30 日 03:53 UTC](https://www.shiqidu.com/t/topic/1853/1 "2026-10-30T03:53:34Z")

</div>

“把 MPTCP 关了就没事”这句话被转了不少次，往下翻却没人贴出处。回到源头看一下：这个 CVE 由 Linux 内核的 CNA 发布，记录 10 月 15 日公开、10 月 24 日更新过一次，描述全文压根没出现 MPTCP。

## 描述里到底写了什么

标题是 “ipv4: free inet\_opt and ireq\_opt after an RCU grace period”。翻成人话：IPv4 的 TCP 建连过程中，请求 socket 上挂的 IP 选项（`ireq_opt`）会直接移交给新建的子连接（`inet_opt`）。读取这份数据的代码只在 RCU 读锁下进行，释放时却调了普通的 `kfree()`，没等宽限期过去。结果就是 `ip_options_build()` 有机会读到已经释放的内存，也就是 use-after-free。

描述里还点了第二个场景，请求 socket 迁移：开了 `net.ipv4.tcp_migrate_req=1`，或者挂了 `BPF_SK_REUSEPORT_SELECT_OR_MIGRATE` 类型的 BPF 程序时，克隆出来的副本和旧对象共用同一份选项，也有类似问题。修法是在 `inet_sock_destruct()` 和 `tcp_v4_reqsk_destructor()` 里改用 `kfree_rcu()`。

IPv6 不受第一个问题影响，因为 `tcp_v6_syn_recv_sock()` 会复制一份选项。迁移那部分在 IPv6 侧同样存在，只涉及 CALIPSO 设置的 `ipv6_opt`，描述说会另出补丁。

问题的源头，描述里也交代了：自从提交 079096f103fa（“tcp/dccp: install syn\_recv requests into ehash table”）以后，请求 socket 的处理不再持有监听锁，这段并发才有了空子可钻。Ubuntu 的 CVE 页上，主线 linux 包连 16.04 都标着 Vulnerable，14.04 才是 Not affected，所以别指望自己的内核“太老不受影响”。

整段讲的都是普通 IPv4 TCP 握手路径。关 MPTCP 能起多大作用，官方材料里没提到，所以它不能当成修复，最多算一个没被证实的说法。把它当成“已处理”记进工单，回头补丁出来反倒容易漏升。

## Ubuntu 这边修到哪了

[Ubuntu 的 CVE 页](https://ubuntu.com/security/CVE-2026-98432)10 月 29 日更新过，优先级标的是 High，CVSS 3.1 打 9.8，CVSS 4.0 是 8.3。主线 `linux` 包的状态摘几行：

- 26.04 LTS：Vulnerable，work in progress，在做的版本是 7.0.0-43.43
- 24.04 LTS：Vulnerable，work in progress，6.8.0-149.149
- 22.04 LTS：Vulnerable，work in progress，5.15.0-203.213
- 20.04 LTS：Vulnerable
- 14.04 LTS：Not affected

云厂商的内核（aws、azure、gcp、oracle 等）状态都单独列，很多也还是 work in progress，用云上镜像的要按自己实际装的包名去对，不能拿主线那行套。HWE 内核同理：24.04 上的 linux-hwe-6.17 和 linux-hwe-7.0 标的都是 Vulnerable，linux-hwe-6.14 那行则写着 Ignored（end of life），还停在这条线上的机器得考虑换内核。

读这张表时注意，work in progress 的意思是修复还在准备，不代表已经能装。页面上那串版本号是正在做的包，apt 里没出来之前，照样算没修。

用容器跑服务的也别松口气。容器和宿主机共用一个内核，换基础镜像对这个 CVE 没有任何帮助，要升的是底下那台机器。用 Debian、RHEL 系或者别的发行版的，同样去各自的安全追踪页查同一个编号。

页面的补丁信息里列了上游修复提交 e3f33b0，紧跟着一句提醒：不建议自己 cherry-pick。等发行版出正式内核包，装完重启，用 `uname -r` 确认跑的确实是新版本，这才算修完。

## 等补丁这几天

`tcp_migrate_req` 按[内核文档](https://docs.kernel.org/networking/ip-sysctl.html)默认就是 0。没手动开过、也没挂迁移类 BPF 程序的机器，第二个场景本来就不沾边。手动打开过的可以评估一下能不能先关掉。但要说清楚，这只碰到迁移那一半，第一个问题照样在，同样不能当成修好了。

其余能做的就比较朴素：盘一下哪些机器直接对公网监听 TCP，盯着 Ubuntu 的安全公告，补丁一出就排期重启。机器多的，按暴露程度排个先后，网关、负载均衡这类直接接外部连接的放前面，测试环境先升一台观察一两天，再往生产推。

你们手上的机器，是等官方内核包，还是已经有别的临时方案在跑？