返回

2026/11/04

CVE-2026-98432：Linux TCP 释放后使用、借助 AI 通过 MPTCP 实现远程 root，以及企业 Linux 防御

Linux IPv4 TCP 处理中的竞争条件、已演示的 MPTCP 远程 root，以及 RHEL、Ubuntu、Oracle Linux 和 Debian 的修复与缓解措施。

信息核实日期：2026年11月3日 | LOGIQ 技术分析

2026年10月，Linux 内核 IPv4 TCP 连接处理中的一个释放后使用（use-after-free，UAF）漏洞 CVE-2026-98432 被公开。Linux 内核 CVE 团队于10月15日发布了通告。10月27日，Anthropic 报告称，其一个未发布的内部研究模型针对带有 MPTCP（Multipath TCP）监听器的 Linux 服务器，演示了无需认证、以 root 权限远程执行命令。关键在于，不应将这一特定的利用条件，与影响普通 IPv4 TCP 服务的更广泛的漏洞和拒绝服务风险混为一谈。

要点速览

  • 该缺陷是普通 IPv4 TCP 连接请求处理中的竞争条件，自 Linux 4.4 起就已存在。漏洞本身并不需要 MPTCP。
  • Anthropic 的远程 root 演示针对的是带有 MPTCP 监听器的服务器；其他 TCP 服务仍面临崩溃、拒绝服务和内存损坏的风险。
  • Red Hat 将该问题评为 Critical（CVSS v3.1 9.8），并于11月1日发布了 RHEL 8、9、10 的修复内核。截至11月3日，Ubuntu 的修复仍在进行中。
  • 请安装厂商认可的修复内核，重启后确认正在运行的内核。缓解措施可以减少暴露面，但不能替代补丁。

竞争条件发生在哪里

该问题涉及 IPv4 TCP 三次握手。请求套接字持有的 IP 选项（ireq->ireq_opt）可能在 tcp_v4_syn_recv_sock() 处理过程中未经复制就被转移到子套接字的 inet_opt。如果另一个 CPU 正在处理重传的 SYN 并构造 SYN/ACK，而此时子套接字被销毁，那么仍在使用中的选项内存可能被释放。之后 ip_options_build() 等函数再访问这块内存，就可能触发 UAF。

通过 net.ipv4.tcp_migrate_req=1 或 BPF_SK_REUSEPORT_SELECT_OR_MIGRATE 进行请求套接字迁移时，也存在相关的竞争条件，原始请求套接字与克隆的请求套接字之间可能共享选项数据。存在漏洞的行为可追溯到 Linux 4.4，但实际暴露情况必须按各厂商内核（包括向后移植的修改）逐一评估。

上游修复提交 e3f33b0a1d89（”ipv4: free inet_opt and ireq_opt after an RCU grace period”）将 inet_sock_destruct() 和 tcp_v4_reqsk_destructor() 中的立即释放改为通过 kfree_rcu() 进行的 RCU 延迟释放。Linux CVE 通告指出，内核版本 6.12.113、6.18.56、7.2.10 和 7.3-rc7 已包含修复。最初的 IPv6 路径并不是同一个漏洞，不过涉及 CALIPSO 的 IPv6 迁移路径由另一个补丁单独处理。

不要把已演示的远程 root 访问与一般暴露混为一谈

Anthropic 的概念验证针对带有 MPTCP 监听器的服务器，结合了内核地址信息泄露和控制流劫持。据报告，该实验花了大约48分钟获得信息泄露，又用了5分钟实现命令执行。由于竞争失败只会导致握手失败而不会使系统崩溃，攻击者可以不断重试。然而，底层的 UAF 位于普通的 IPv4 TCP 连接请求处理中，而不仅仅存在于 MPTCP 代码中。

同样的远程 root 利用技术并未在所有不使用 MPTCP 的常规 TCP 服务上得到演示。但认为禁用 MPTCP 就能让系统完全安全，同样是错误的。Red Hat 表示，MPTCP 并非必要条件，禁用 MPTCP（默认设置）的系统仍然受影响，并警告标准 IPv4 TCP 服务可能遭受无需认证的远程崩溃、拒绝服务和内存损坏。

主要厂商评估：严重程度与修复状态

以下为2026年11月3日核实时的状态。厂商页面会更新，采取行动前请务必查看最新条目。

厂商严重程度修复状态
Red HatCritical，CVSS v3.1 9.811月1日发布修复内核：RHEL 8（RHSA-2026:93414；面向 NFV 的 kernel-rt 为 RHSA-2026:93415）、RHEL 9（RHSA-2026:93412）、RHEL 10（RHSA-2026:93413）。RHEL 9 kernel-rt 和 OpenShift（RHCOS）仍列为 Affected。RHEL 6 和 7 不受影响。
Ubuntu优先级 High；CVSS 9.826.10、26.04、24.04 和 22.04 的 linux：Vulnerable，修复进行中。20.04、18.04 和 16.04：Vulnerable。尚未发布修复软件包。
Oracle LinuxImportant；暂定 CVSS 8.1面向 OL7 至 OL10 的 UEK 勘误（ELSA-2026-500397、-500398、-500399）日期为10月16日。面向 OL8（ELSA-2026-93414）和 OL10（ELSA-2026-93413）的 RHCK 勘误日期为11月2日；OL9 尚无 RHCK 勘误。
Debian（Security Tracker）已在 bookworm 6.1.190-1（DLA-4841-1）、bookworm linux-6.12 6.12.113-1~deb12u1（DLA-4850-1）和 trixie 6.12.113-1（DSA-6568-1）中修复；forky 和 sid 已修复。

Red Hat（评估于10月30日修订；公告最后更新于11月2日）。官方 CVE 页面将该问题评为 Critical，CVSS v3.1 9.8，理由是未经认证的远程攻击者可以通过普通 IPv4 TCP 流量破坏内核内存或使系统崩溃。RHEL 8、9、10 和 OpenShift 被列为受影响；RHEL 7 内核因不包含相关代码而被列为不受影响。自11月1日起，Red Hat 的 CVE 数据列出了修复内核：kernel-4.18.0-553.182.1.el8_10（RHEL 8）、kernel-5.14.0-687.64.1.el9_8（RHEL 9）和 kernel-6.12.0-211.72.1.el10_2（RHEL 10）。安全公告 RHSB-2026-016 仍标记为进行中，缓解步骤请以该公告为准。不要把 5.9 或 8.1 等来自二手资料的旧评分当作 Red Hat 当前的评估。

Ubuntu（官方表格最后更新于10月30日）。CVE 的 CVSS 为 9.8，而 Ubuntu 自身的优先级为 High。Ubuntu 26.10、26.04、24.04 和 22.04 的标准 linux 软件包标记为 “Vulnerable, work in progress”，页面上显示了计划中的修复版本；20.04 等版本标记为 Vulnerable。AWS、Azure、HWE、RT 等内核变体必须单独评估。”work in progress” 并不表示修复已经发布。

Oracle Linux。Oracle 自己的评估为 Important，暂定 CVSS 评分为 8.1。面向 OL7、OL8、OL9 和 OL10 的 UEK 勘误日期为10月16日，面向 OL8 和 OL10 的 RHCK 勘误于11月2日随后发布。不能把 UEK 中的修复推广到 RHCK 或所有次要版本；请评估已安装的内核和确切的勘误。

Debian。官方 Security Tracker 将 bookworm-security 6.1.190-1 和 trixie-security 6.12.113-1 等标记为已修复。请同时核实已安装的软件包版本以及重启后正在运行的内核。

由于各发行版特有的配置和修复，CNA 与厂商之间的 CVSS 结果可能不同，评估也可能发生变化。请始终记录核实日期，并链接到各个官方来源。

防御措施：缓解措施不能替代补丁

首要任务是安装厂商认可的修复内核，并在重启后核实正在运行的版本。在修复尚未发布的情况下，可以考虑关闭不必要的对外 TCP 服务、限制允许的来源网络，并优先监控暴露在外的主机。

Red Hat 的公告介绍了一种 nftables 缓解措施，用于丢弃 IPv4 头中带有 IP 选项的入站 IPv4 TCP 数据包：

table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}

这并不是完整的防护，可能会干扰依赖 IP 选项的工作负载，部署前必须测试其对业务流量的影响。TCP 头中的普通 TCP 选项仍然允许通过；这并不是要阻止 TCP Options 字段。在 OpenShift 上，节点级规则不会过滤集群网络内部 Pod 之间的流量，因此在网络边界进行过滤尤为重要。修复内核运行后，请删除该表。

提示：打补丁后，将 uname -r 的输出与厂商勘误中的修复版本进行比较，并将该输出与变更记录一起保存。已安装但尚未启动的软件包并不能消除漏洞。

在 Linux 上，Go 1.24 及更高版本的 Go net 包默认为监听器启用 MPTCP。Go 团队在文档中说明可以用 GODEBUG=multipathtcp=0 将其禁用（也可以在 go.mod 中以 godebug 行的形式设置）。更改默认值的提案仍在讨论中，Go 维护者指出，真正的修复是打过补丁的内核。该设置可以减少对 Anthropic 所演示的依赖 MPTCP 的攻击路径的暴露，但并不能修复内核 UAF 本身。请逐个服务审查 MPTCP 的使用情况。

LOGIQ 的观点

企业 Linux 运维不能仅凭公开的 CVSS 分数或 uname -r 来判断是否安全。应综合评估操作系统版本、内核系列（例如 UEK 与 RHCK）、软件包版本、当前启动的内核、网络暴露情况、MPTCP 设置、厂商勘误和重启证据。要跟踪从影响评估、验证到部署和运行监控的整个链条。

在厂商修复尚未发布时，应记录临时缓解措施下的剩余风险，并在补丁发布后重新评估这些缓解措施。随着 AI 提高了漏洞被实际利用的可能性，企业运维必须覆盖完整的生命周期：检测、验证、修复以及运行正常的证据。

一手来源与参考资料