CVE-2026-98432 内核补丁进 Ubuntu 测试源，VPS 先查这两处

发表于 分类于
Ubuntu 22.04/24.04/26.04 的 CVE-2026-98432 修复内核 11 月 2 日进入 -proposed 测试源，RHEL 11 月 1 至 3 日已发修复包；本文说明如何核对本机内核、查 MPTCP 监听，以及为什么只关 MPTCP 不算修好。

本文依据 Ostorlab、Sentilio 等 11 月 2 至 3 日的安全分析整理，未实测。这是 11 月 1 日那篇 Xray-core v26.10.31 文章的后续：那篇讲的是把 Xray 自身监听口上的 MPTCP 关掉，这篇讲的是另一半——发行版内核补丁到底到了没有，以及怎么核对你的 VPS 是不是真的修好了。两件事要分开做，只做一件不算完。

11 月 2 至 3 日的新进展：补丁开始落地，但渠道不一样

CVE-2026-98432 是 Linux 内核 IPv4 TCP 握手路径里的 use-after-free，内核 CVE 团队评分为 CVSS 3.1 9.8，影响 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。11 月 2 至 3 日各发行版的进度并不一致，这正是容易踩坑的地方：

  • Ubuntu 22.04 LTS、24.04 LTS、26.04 LTS 的修复内核于 11 月 2 日进入 -proposed 测试源，对应版本分别是 5.15.0-203.213、6.8.0-149.149、7.0.0-43.43；但常规 updates 源何时收到没有给出日期。Ubuntu 安全追踪页在 11 月 3 日仍把这三个版本标为易受攻击，原因是追踪页不把 -proposed 里的包算作已发布修复。所以不要只看追踪页的“易受攻击”就下结论，也不要以为跑一遍普通 apt upgrade 就已经修好了。
  • Ubuntu 26.10 的修复版本在 Canonical 的文章里写作 7.3.0-10.10，但其 CVE 页面当时仍显示为处理中，两处口径不一致，以实际装上的包为准。
  • RHEL 在 11 月 1 至 3 日陆续发布了修复内核，11 月 1 日的三批包括 RHEL 9.8 的 RHSA-2026:93412、RHEL 10.2 的 RHSA-2026:93413、RHEL 8.10 的 RHSA-2026:93414，11 月 2 至 3 日还有针对扩展支持版本的 errata。
  • Debian 的修复包到得更早：Debian 13 是 6.12.113-1，Debian 12 是 6.1.190-1。
  • 仍无修复的要单独记下来：截至 11 月 3 日，RHEL 9 的 kernel-rt 没有已发布的修复，Ubuntu 16.04 至 20.04 也没有公布修复版本，SLES 15 SP7 的修复仍在处理中。

另外一个状态更新：截至 11 月 3 日，该漏洞未进入 CISA 的已知被利用漏洞目录，也没有厂商报告野外利用案例；Anthropic 演示的利用代码没有公开。有安全厂商转述称已出现针对 MPTCP 服务器的扫描迹象，但这只是扫描迹象，不是已确认的成功利用，不要把它写成“已经在被打”。

先查这两处：本机内核和 MPTCP 监听

动手升级之前，先确认自己到底处在什么状态。第一处是本机正在运行的内核：

1
uname -r

注意 uname -r 显示的是当前运行的内核，不是刚装好还没重启的新内核。装完修复包必须重启，重启后再跑一遍 uname -r，确认版本号确实变到了修复版本，才算生效。

第二处是 MPTCP 监听。Go 1.24 起的程序在 Linux 上默认会把监听 socket 开成 MPTCP，所以很多 Go 服务（包括 Xray 这类 Go 程序）可能在管理员不知情的情况下暴露了 MPTCP 监听。先看系统是否允许打开 MPTCP，再列出实际的 MPTCP 监听：

1
2
sysctl net.mptcp.enabled
sudo ss -Mlnp

sysctl net.mptcp.enabled 输出 1 只表示程序可以打开 MPTCP socket，不等于已经有 MPTCP 监听；ss -Mlnp 只列 MPTCP socket，没有输出就表示没有这类监听，有输出则要看清是哪个进程在监听，再决定先升级还是先关。

各发行版怎么升：只看自己那一行

Debian 用户按常规升级内核包再重启即可（以下为来源给出的写法，本文未实测）：

1
apt update && apt install linux-image-amd64

RHEL 用户升级到对应小版本的 erratum 内核再重启，例如 RHEL 9.8：

1
sudo dnf update kernel && sudo reboot

Ubuntu LTS 用户要特别注意：修复包在 -proposed 测试源里，不是常规源。来源给出的做法是先把 -proposed 口袋加进来，只升级内核包，再重启（本文未实测，生产机先在测试机上验证）：

1
2
3
4
sudo add-apt-repository --component main --pocket proposed http://archive.ubuntu.com/ubuntu
sudo apt update
dpkg-query -W -f '${source:Package}\t${binary:Package}\n' | awk '$1 ~ "^linux-meta" { print $2 }' | xargs sudo apt install -t $(. /etc/os-release && echo $VERSION_CODENAME)-proposed --only-upgrade
sudo reboot

重启后同样用 uname -r 核对。如果不想进测试源，就只能等常规 updates 源收到修复包，来源没有给出这个时间，不要自己编一个日期。

只关 MPTCP 为什么不算修好

如果暂时拿不到修复内核，可以先把 MPTCP 关掉当作临时缓解，但必须说清它的边界：

1
sudo sysctl -w net.mptcp.enabled=0

上面这条只改运行中的内核设置，重启后会恢复；要持久化可以写入 sysctl 配置文件：

1
echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/99-disable-mptcp.conf

已经建立的 MPTCP 监听不会因为改了这个开关就自动变成普通 TCP，需要重启对应服务后，再用 sudo ss -Mlnp 确认监听已经消失。

Go 1.24 以后的服务还有一层单独的开关：在程序环境里设置 GODEBUG=multipathtcp=0 可以关掉该程序的 MPTCP 默认行为。但 Go 安全团队自己的提醒是：逐个程序关 MPTCP 是脆弱的缓解办法，只要还剩一个 MPTCP 监听，风险就没有清零；而且该漏洞的根源在普通 IPv4 TCP 处理路径上，Red Hat 的公告也指出 MPTCP 不是触发该漏洞的必要条件，默认关闭 MPTCP 的 OpenShift 节点同样受影响。所以关 MPTCP 只是先拆掉 Anthropic 演示的那条利用链，真正关门还是要靠修复内核。

和 Xray 那篇的关系，一句话说清

11 月 1 日的文章讲的是 Xray-core v26.10.31 默认关闭 MPTCP、v26.10.29 被撤版；那一步只解决 Xray 自身监听口的问题。今天这篇讲的是内核那一步：发行版修复包到了哪个渠道、本机怎么核对、重启后怎么确认。面板用户还要注意，面板捆绑的 Xray-core 版本和系统内核版本是两回事，面板里显示的内核版本不代表系统内核已经修复，系统内核以 uname -r 为准。

依据来源