CVE-2026-98432：Linux TCP 释放后使用漏洞与补丁验证

CVE-2026-98432 是 Linux 内核 IPv4 TCP 握手路径中的一个释放后使用（use-after-free）漏洞。当两个处理器分别操作相关的 request socket 和 child socket，且二者仍可引用同一个 IP options 对象时，该缺陷便会显现。一条路径可能立即释放该对象，而另一条仅受 RCU 读侧保护的路径仍继续使用它。结果是在可通过网络流量触达的代码中留下一个失效的内核指针。

Linux CNA 记录给出的 CVSS 3.1 评分为 9.8。各发行版的评估必须结合其自身产品和指标版本解读；对于 RHEL，应查阅当前的 Red Hat 安全公告，而不是把上游评分套用到所有发行版。另外，Anthropic 报告称，在受控实验室环境中，针对一台运行 Multipath TCP 监听器的服务器实现了远程 root 命令执行。这表明在特定配置下存在严重的可利用性，但并不意味着所有 Linux TCP 监听器都会被普遍攻陷。

防御者应将这些说法视为互补信息。上游记录指出了危险的內存生命周期错误及其理论上的最大影响。发行版评分描述的是厂商实际发布的代码、配置、缓解措施和预期利用条件。研究性利用则展示了针对特定目标的一条具体攻击路径。三者都不应被舍弃，也都不应被超出其适用范围地引申。

实际的应对措施很直接：识别可触达的 Linux TCP 服务，确定实际运行的是哪个厂商内核，安装厂商提供的修复版本，重启进入该版本，并保留运行内核包含该修复的证据。暴露 MPTCP 监听器的主机应优先处理，因为公开研究已专门验证了该环境。面向互联网的网关、负载均衡器、Kubernetes 节点、VPN 端点、反向代理，以及使用 Linux 网络栈的设备，即使并未有意启用 MPTCP，也应尽快清点。

对于在 AlmaLinux 或 Ubuntu 上查找 CVE-2026-98432 的管理员，必须针对确切的发行版版本和内核变体核对软件包状态。在 2026 年 10 月 30 日的本次研究快照中，无法从针对该 CVE 的官方公告独立确认 AlmaLinux 的状态；Ubuntu 则发布了实时的逐包跟踪器。不要将缺少公告证据解读为安全的证明。

CVE-2026-98432 与 Linux 内核 TCP 缺陷

权威的技术描述来自 Linux 内核 CVE 流程和上游补丁。该问题涉及与 TCP request socket 关联的 IPv4 选项数据的所有权和回收。在 TCP 握手的服务器端，内核会创建一个轻量级 request socket，用于表示尚未成为完整 child socket 的连接。当握手推进时，tcp_v4_syn_recv_sock() 会将 request 的 ireq_opt 指针作为 inet_opt 转移给新的 child socket，而不会复制该对象。

与此同时，另一个 CPU 可能处理与同一 request 关联的重传 SYN。第二条路径可以通过 tcp_check_req() 再发送一个 SYN-ACK。tcp_v4_send_synack() 和 inet_csk_route_req() 等函数会在 RCU 读侧临界区内读取 request 的 IP 选项。后续的辅助函数（包括 ip_build_and_send_pkt() 和 ip_options_build()）会解引用该选项对象中的字段。Debian 安全跟踪器复现了上游的解释，并将该问题映射到已修复的 Debian 内核软件包。

生命周期不匹配是核心问题。读取方以为 RCU 保护着该对象，但析构函数却用普通的 kfree() 将其释放。普通的 kfree() 会让这块分配可供复用，而不必等待现有的 RCU 读取方完成。如果在重传 SYN 路径仍在使用 options 时子套接字被销毁，第二个 CPU 就可能继续读取已不属于该对象的内存。上游的主要修复方案是在相关析构函数中用 kfree_rcu() 替代立即释放，将回收推迟到 RCU 宽限期结束之后。

该漏洞还有一个相关的请求迁移场景。如果启用了 net.ipv4.tcp_migrate_req=1，或者某个 BPF_SK_REUSEPORT_SELECT_OR_MIGRATE 程序控制请求迁移，内核可能会克隆一个请求套接字。旧请求及其克隆可能暂时共享同一个 options 对象。持有旧请求引用的 CPU 仍可能使用该对象，而克隆已被释放。因此内核描述将 inet_sock_destruct() 和 tcp_v4_reqsk_destructor() 都改为使用感知 RCU 的回收方式。

第一个问题特定于 IPv4 子套接字路径，因为对应的 IPv6 函数是复制 options，而不是转移同一个指针。上游文本还提到，当存在 CALIPSO 时，IPv6 请求迁移涉及 ipv6_opt 的隐患，并表示该情况另行处理。这一区分很重要：说“IPv6 不受影响”过于宽泛，而说主要的 IPv4 所有权转移缺陷不适用于普通 IPv6 子套接字创建路径则是准确的。

该补丁已作为提交 e3f33b0a1d89 合入上游，标题为“ipv4: free inet_opt and ireq_opt after an RCU grace period”。Ubuntu CVE 页面 标出了相同的引入提交和修复提交，并独立跟踪了许多 Ubuntu 内核变体。这是有用的证据，说明通用的内核版本检查无法替代发行版特定的状态。

尚未确立的事实

此处引用的任何权威来源都未证实该漏洞在公共互联网上被广泛利用。Anthropic 证实其研究人员可以针对一个带有 MPTCP 监听器的受控目标，将该缺陷转化为远程 root 命令执行。这比仅能导致崩溃的证明更有力，应影响紧迫性判断。但它仍未提供存在漏洞的 MPTCP 服务的实测普遍程度、通用成功率，也未证明同一利用链在内核构建、CPU 架构、分配器、加固配置和网络路径不同的情况下都能原样奏效。

公开材料也不足以支持将任何大量 SYN 重传都视为利用行为。重传的 SYN 数据包会因丢包、非对称路由、服务过载、客户端重试行为和中间盒而自然出现。利用竞态条件可能产生异常模式，但这些模式需要与存在漏洞的主机、相关 options、内核症状和时序进行关联。网络告警可以优先安排调查，但不能证明内核内部发生了释放后使用。

没有任何单一的上游版本字符串能够准确标记所有厂商内核。企业发行版通常会回移安全修复，同时保留看起来较旧的基础版本。云服务提供商和设备厂商可能会发布自己的内核构建。仅将 uname -r 与上游发布列表进行比对的扫描器可能同时产生误报和漏报。可靠的结论来自厂商公告、软件包变更日志、构建元数据、VEX 声明，或直接确认相关修复提交已被回移。

最后，禁用 MPTCP 并不能消除底层的 IPv4 生命周期缺陷。它移除了公开研究链中使用的确切监听器配置，并可在不需要 MPTCP 的场景中切实降低即时暴露风险。上游技术描述涵盖了普通 IPv4 TCP 请求与子套接字路径以及请求迁移。补丁部署仍是持久的修正方案。

易受攻击的 TCP 路径如何工作

TCP 服务器通常接收 SYN，回复 SYN-ACK，然后等待最终的 ACK。内核避免在第一个数据包时就分配完整的已连接套接字，否则攻击者可以廉价地耗尽资源。相反，它会创建一个紧凑的请求套接字，存储足够的状态以验证并完成握手。当 ACK 到达且连接被接受时，内核创建一个完整的子套接字，并将选定的状态移动或复制到其中。

IPv4 选项使这一转换变得复杂。IP 选项可以携带影响路由或数据包处理的元数据。内核解析传入的信息并存储内部表示，以供后续构造响应时使用。在受影响的路径中，请求套接字的 ireq_opt 指针成为子套接字的 inet_opt 指针。该转移避免了复制，但这意味着一个分配的生命周期跨越了两个套接字对象之间的边界。

在握手状态完全稳定之前，同一连接元组的第二个 SYN 可能到达。重传是 TCP 的正常组成部分。内核可能在另一个 CPU 上处理该 SYN，并使用原始请求套接字构建 SYN-ACK。由于 Linux 网络高度并行，子套接字可能在另一个 CPU 仍在构造回复时已推进至拆除阶段。请求路径获取 RCU 读锁，表明其读取的数据必须在读侧临界区结束前保持有效。

旧的析构函数行为违反了这一预期。子套接字没有携带会推迟其整体释放的 SOCK_RCU_FREE 行为，而 inet_sock_destruct() 直接释放了 inet_opt。第二个 CPU 可能保留该指针，并从已归还给分配器的内存中读取 optlen。后续的分配可能在该地址放置无关数据，从而在读取之间改变值，或让后续代码操作受攻击者影响的内容。

释放后使用漏洞之所以危险，是因为其直接症状取决于什么替换了被释放的分配。陈旧访问可能读到旧字节，看起来无害。它可能遇到被投毒或未映射的内存并崩溃。它可能读到新的内核对象并泄露数据。如果对分配模式和时序有足够的控制，研究人员可能将陈旧引用转化为更强大的读、写或控制流原语。因此，该漏洞类别支持从间歇性握手失败到拒绝服务再到代码执行的各种结果，但必须针对特定目标演示特定结果。

请求迁移变体通过不同的拓扑遵循相同的生命周期原则。Reuseport 允许多个套接字共享一个监听端口，BPF 可以参与选择目标。当监听器改变状态时，请求迁移可能移动待处理的连接。内核克隆请求状态，创建一个窗口，其中两个请求对象引用同一个选项分配。清除一个对象中的指针并不能保护已经持有其引用的 CPU。如果另一个对象的析构函数立即释放共享分配，该读取者就会变得陈旧。

该补丁并不试图将所有操作串行化在一个全局锁之后。那会损害热网络路径中的可扩展性。相反，它使回收与读取者已经使用的同步模型保持一致。这正是 Read-Copy Update 旨在解决的问题类型。

为什么 RCU 改变了安全边界

Read-Copy Update 让读取者以极低开销访问共享数据，而写入者发布替换并延迟释放旧版本。读取者进入 RCU 读侧临界区，获取指针，使用对象，然后退出。写入者可以从数据结构中移除对象，使新读取者不再找到它，但必须在回收内存之前等待宽限期。宽限期确保所有可能看到旧指针的读取者都已完成。

Linux 内核的 RCU 文档 描述了基本的移除与回收分离。移除改变可达性。回收将存储返回给分配器。混淆这些操作是释放后使用错误的常见来源。RCU 锁不会在任意对象上放置引用计数，也不会使直接 kfree() 安全。相应的写入者必须使用 RCU 感知机制，例如 call_rcu() 或 kfree_rcu()。

在 CVE-2026-98432 中，读取路径已经使用 RCU。修正使析构函数遵守该契约。kfree_rcu() 在宽限期后安排对象释放，而不是立即释放。构建 SYN-ACK 的 CPU 可以完成读取旧选项对象。后续读取者将不再获得它，并且只有在先前存在的读取者消失后，分配才可重用。

这种设计保持了并发性。它不要求服务器停止处理重传，在握手构建周围放置大锁，或为每次读取复制选项对象。安全属性狭窄而明确：对 RCU 读取者可见的对象在其可能访问的持续时间内保持分配。

RCU 修复也解释了为什么仅靠数据包过滤无法成为完整的补救措施。内存安全缺陷存在于对象生命周期管理中。过滤可能使触发条件更难达到，禁用不需要的功能可以减少路径集合。只有修正后的回收机制才能为到达代码的每个合法和恶意数据包恢复不变量。

为什么上游和发行版的严重性评估不同

CVE 记录的 CVSS 3.1 向量为 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，得出 9.8。该向量假设网络攻击者不需要账户、不需要用户交互，攻击复杂度低，且成功利用可在机密性、完整性和可用性方面产生高影响。它表达了 CNA 对易受攻击的上游组件的基础特征描述。

Ubuntu 显示该 9.8 值，但也发布了 CVSS 4.0 评估为 8.3，并注明存在攻击要求。CVSS 4.0 可以表示无法干净地纳入旧向量的先决条件。Ubuntu 的页面将该漏洞标记为高优先级，并公开逐包状态，而不是将数字评分视为整个决策依据。

Red Hat 的产品评估和修复状态属于其实时公告中列出的确切 RHEL 产品和内核包。在未检查该来源的情况下，不要将早期的初步评分带入当前的风险决策。发行版评估不能确定在另一供应商的构建上可利用性，MPTCP 研究结果也不能确定在每个 RHEL 配置上产生相同结果。

对于以不同形式分发的开源组件，CVSS 分歧很常见。同一源缺陷可能存在于两个产品中，但通过不同配置暴露。一个供应商可能默认启用某功能，另一个可能省略它，第三个可能携带改变可达性的部分向后移植。内核加固、分配器行为、架构、编译器选项和服务拓扑都可能影响漏洞利用开发，而不改变易受攻击的源代码行。

对于运营优先级排序，单一通用评分不如简短的环境特定分析有用：

Linux CNA 评分、供应商产品评估和 MPTCP 实验室演示回答的是不同问题。它们都没有衡量漏洞利用的普遍性。在设定补丁优先级时，应在各自范围内使用。

多路径 TCP 监听器研究证明了什么

Anthropic 10 月 27 日的研究文章描述了一种针对运行 Multipath TCP 监听器的服务器的远程零点击 Linux 内核漏洞利用。据研究人员称，该漏洞利用分两个阶段利用了竞态引发的释放后使用（use-after-free）。第一阶段获取了内核指针并绕过了内核地址空间布局随机化（KASLR）。第二阶段将内存破坏转化为控制流劫持，最终以 root 身份执行了攻击者选定的命令。

该团队报告称，其概念验证大约用了 48 分钟泄露内核指针，又用了五分钟达到命令执行。一次失败的尝试可能使握手保持不完整，而不一定会导致主机崩溃，从而允许反复尝试。这一行为之所以重要，是因为当失败代价低廉且重试机会充足时，竞态条件漏洞利用往往变得可行。

该研究是可信的证据，表明该漏洞的影响可能超出拒绝服务。它还告诉防御者哪类公开暴露应获得最高优先级：在存在漏洞的内核上，对启用 MPTCP 的监听器的不可信网络访问。官方 Linux MPTCP 文档解释了 Multipath TCP 如何扩展普通 TCP，使连接可以使用多个子流，同时保持与现有应用程序兼容。Linux 发行版可能提供 MPTCP 支持，但并非每个应用或服务都在使用它，因此管理员需要检查运行时状态和监听器，而不是根据软件包是否存在来推断暴露情况。

已发布的摘要并非可复用的漏洞利用配方。它省略了复现堆状态、时序、地址泄露和可靠控制所需的特定于目标的细节。负责任的防御并不需要在生产系统上复现这些阶段。一个可用的研究利用链、协调披露、上游修复和稳定的向后移植，已提供足够的证据来进行修补。

有几条边界应保持明确。研究目标使用了 MPTCP。内核构建各不相同。报告的时间是一次实验结果，并非保证的最小值或最大值。网络延迟、CPU 数量、负载、分配器行为、加固措施和服务实现都可能改变竞态。该文章并未声称每个发行版上使用默认设置的普通 TCP 服务同样可被利用。

因此，最站得住脚的说法是：CVE-2026-98432 可通过 Linux 网络远程触达；Anthropic 在受控环境中针对存在漏洞的 MPTCP 监听器演示了未认证的 root 代码执行；更广泛的利用性和可靠性取决于目标。这一表述既保留了紧迫性，也保留了准确性。

受影响版本与厂商向后移植

该漏洞行为由较早的上游变更引入，包括提交 079096f103fa，该提交允许在未持有监听器锁的情况下将 TCP 和 DCCP 请求套接字安装到已建立哈希表中，以及另一项与请求迁移相关的变更。由于受影响的历史跨越许多维护分支，Linux CVE 记录列举了各分支特定的修复，而不是一个简单的易受影响范围。

上游稳定修复已发布到各维护分支。公开记录中首批修正版本包括 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10，以及包含主线修复的 7.3 开发分支。这些版本号对上游内核有用，但不能作为厂商软件包的通用规则，因为厂商可能将修正回移植到基础版本号更低的构建中，或维护带有额外修订标识符的分支。

例如，Debian 的跟踪器将 Bookworm 的 6.1.190-1 安全包和 Trixie 的 6.12.113-1 包标记为已修复，还记录了后续套件中的修复构建。这些包版本才是 Debian 系统的正确证据。在 Ubuntu 上，安全页面列出了许多独立的内核源码包，包括 generic、AWS、Azure、GCP、KVM、Oracle、OEM、低延迟和实时变体。一个变体的状态不能自动证明另一个变体也已修复。

Red Hat 客户应使用适用于确切 RHEL 或 OpenShift 产品的 Red Hat CVE 页面和勘误。企业内核有意保留稳定接口和版本系列，同时纳入安全补丁。仅依据版本、期望上游首个修复版本的扫描器可能会误报已修正的 Red Hat 内核。反之，在设备中看到较高的基础版本号，并不能证明厂商包含了所有稳定补丁。

对于各自的产品，应查阅 SUSE CVE 页面、Gentoo 安全公告、云提供商通知和设备厂商公告。当厂商尚未发布判定时，管理员可以要求提供 VEX 或支持声明，说明是否存在易受攻击的代码以及哪个构建包含修复。

容器需要特别关注。容器通常共享主机内核。更新应用镜像并不会替换处理其 TCP 流量的内核。托管 Kubernetes 客户可能需要更新节点镜像、滚动更新节点池或执行提供商维护操作。自管理集群需要更新主机软件包并重启节点。替换后，应验证每个节点，而不是假设控制平面滚动更新已覆盖整个集群。

实时补丁可能覆盖也可能不覆盖此更改。该修正影响网络析构函数中的对象回收，覆盖范围取决于厂商的实时补丁实现和支持决定。仅当厂商明确将其与 CVE-2026-98432 关联时，才将实时补丁状态视为有效。如果不存在此类确认，请安装修复后的内核并重启。

CVE-2026-98432 的平台验证

检查于 2026 年 10 月 30 日。将此 Linux 内核漏洞视为内核软件包调查：平台名称、已安装的更新和当前运行的内核是三种不同的证据。

Proxmox：验证主机内核和已安装的软件包

在每个 Proxmox VE 主机上运行以下只读清单，而不是依赖客户机的发行版标签：

uname -r
pveversion -v
dpkg-query -W 'proxmox-kernel*' 'pve-kernel*'
proxmox-boot-tool kernel list

将正在运行的内核版本与已安装的版本化内核包及其软件仓库进行对比。查看节点的 Updates 视图、适用的 Proxmox 更新公告以及该包的变更日志，以确认修复内容或明确的厂商映射。如果变更日志无法确认已包含修复，请在将主机标记为已修复之前获取 Proxmox 支持确认。Proxmox VE 管理指南描述了可引导内核的选择；已安装的更新可以与选择用于引导的较旧内核共存。维护重启后，在每个节点上重复 uname -r，并确认预期的厂商修复版本已处于活动状态。

社区讨论是核查源码历史和软件包变更日志的线索，而非对 Proxmox 已修复版本的官方确认。本审查不会根据论坛说法指定首个修复的 Proxmox 版本，也不会假定 Ubuntu 跟踪表中的一行即可确立 Proxmox 软件包的状态。LXC 工作负载使用主机内核；Linux 虚拟机拥有自己的客户机内核，需单独评估。

AWS：区分 EC2 客户机、发行版镜像与托管服务

对于自管理的 EC2 实例，需确定客户机操作系统、内核类型、已安装软件包和活动内核。EC2 责任共担指南将客户机操作系统的更新和安全补丁归于客户。Ubuntu linux-aws 软件包仍需 Canonical 针对具体发行版作出判定；Amazon Linux 的公告无法确立其状态。

对于 AWS 提供的 Amazon Linux 镜像，需确定 AMI 和 Amazon Linux 发行版，然后查阅 Amazon Linux CVE 软件包矩阵。在本次检查时，Amazon Linux 2023 kernel6.12 和 kernel6.18 分别在 ALAS2023-2026-3335 和 ALAS2023-2026-3251 下被列为已修复，而所列的 Amazon Linux 2 分支和 Amazon Linux 2023 kernel 仍待修复。这些是软件包分支层面的判定，并不表示所有 Amazon Linux 实例均已修补。

kernel6.18 公告列出了受支持架构的 6.18.56-125.164.amzn2023 软件包。更新前，请将确切的软件包和架构与适用的公告进行匹配，然后在重启后验证内核。请查看实时公告以了解其他分支。较新的 AMI 不会更新已在运行的实例；还需更新启动模板，并替换或修补现有节点。

对于托管服务，请使用该服务自身的安全公告、维护指南和责任模型。AWS 按服务分配补丁责任；某些客户管理的节点仍需客户采取行动。EC2 客户机内核字符串或通用的 Linux 受影响范围，均不能证明 AWS 的底层主机或每项托管服务受到影响或已修复。

AlmaLinux：受影响与已修复状态仍未确认

本次 10 月 30 日的审查未核实到明确针对 CVE-2026-98432 的 AlmaLinux 公告及相应已修复内核 RPM。请保持状态为未确认。请查阅 AlmaLinux 官方勘误以获取确切的主版本、架构和内核软件包；仅当公告或厂商确认将该 CVE 映射到该发行版及其修正后的软件包时，才更新此判定。RHEL 兼容性以及 RHEL 的受影响或已修复状态，均不能提供 AlmaLinux 的判定。

cat /etc/os-release
uname -r
rpm -q kernel kernel-core
rpm -q --whatprovides "kernel-uname-r = $(uname -r)"

这些命令收集本地证据；它们不能确定软件包是否包含修复。请将其结果与 AlmaLinux 自身的公告进行对比。在安装已确认的修正并重启后，请重复运行内核和软件包检查。

Ubuntu：匹配发行版与内核类型

Ubuntu CVE 跟踪器于 10 月 29 日更新，其中列出 26.10、26.04 LTS、24.04 LTS 和 22.04 LTS 的 generic linux 行在本次检查时处于易受攻击状态且修复工作仍在进行中。进行中的版本并非已发布的修复。请检查实际云、OEM 或其他内核类型的单独行，并在部署时重新核查。

在变更窗口前建立暴露清单

一份好的清单会将漏洞存在性与攻击可达性区分开来。存在性询问正在运行的内核是否包含未修正的受影响代码。可达性询问哪些不受信任的网络和服务能够触发相关的握手路径。两者都很重要。一台存在漏洞但处于隔离状态的实验室主机可以按计划更新窗口处理，而一个公开的 MPTCP 服务则应排在队列最前面。

从直接在 Linux 上终止 TCP 的系统开始：反向代理、Web 服务器、API 网关、入口节点、VPN 集中器、负载均衡器、邮件网关、DNS-over-TCP 服务、SSH 堡垒机、数据库端点和自定义守护进程。如果设备厂商在内部将其标识为 Linux，也应纳入其中。一个外观像硬件的边缘产品仍可能暴露 Linux 网络栈。

确定是否有单独的设备终止外部连接。云负载均衡器可能吸收公共握手并向后端建立第二条连接。这可以减少后端内核从互联网直接可达的程度，但负载均衡器本身以及任何内部不受信任的客户端仍在范围内。请在资产记录中保留实际连接路径，而不是依赖省略了网络终止环节的应用架构图。

检查 MPTCP 状态。在具有适当 iproute2 版本的系统上，ip mptcp endpoint show 和 ip mptcp limits show 可以显示已配置的端点和限制。在可用的情况下检查 sysctl net.mptcp.enabled。同时识别有意创建 MPTCP 套接字的应用程序；仅有一个全局启用标志并不能证明存在监听器。MPTCP 上游项目文档提供了测试和部署参考。

使用 sysctl net.ipv4.tcp_migrate_req 检查请求迁移设置。默认值和可用性可能因内核和配置而异。值为 1 会增加上游所述迁移路径的相关性。识别附加到监听组的 reuseport BPF 程序。内核的 IP sysctl 文档解释了请求迁移和 BPF_SK_REUSEPORT_SELECT_OR_MIGRATE 策略。这些功能的缺失并不能证明主要 IPv4 路径是安全的，但其存在有助于确定测试和推广的优先级。

记录有效内核、软件包、启动镜像、架构和厂商。对于不可变系统，记录节点镜像或操作系统发行版。对于设备，记录固件。对于托管服务，记录提供商公告或支持案例。这些证据比仅写着“Linux”的电子表格单元格更有用。

映射信任边界。仅可从企业 VLAN 访问的服务仍可能被受感染的笔记本电脑、工作负载或合作伙伴访问。Kubernetes 节点端口可能以不同于入口配置的方式暴露监听器。即使在偏好 IPv6 的组织中，IPv4 暴露仍然相关，因为双栈服务和管理网络通常保持 IPv4 启用。

在不产生漏洞利用流量的情况下进行安全验证

生产环境验证应回答四个问题：正在运行的是哪个内核、由哪个厂商软件包提供、相关服务是否可达，以及厂商是否声明该确切构建已修复。它不应尝试赢得竞态、破坏内核内存、泄露地址，或通过概念验证执行命令。

以下命令在您管理的系统上收集本地事实。它们不会触发该漏洞：

uname -a
uname -r
cat /etc/os-release

# Debian and Ubuntu package evidence
dpkg-query -W 'linux-image*' 2>/dev/null | sed -n '1,40p'

# RHEL-family package evidence
rpm -q kernel kernel-core 2>/dev/null

# Listening TCP sockets
ss -lntp

# MPTCP state when supported
sysctl net.mptcp.enabled 2>/dev/null
ip mptcp endpoint show 2>/dev/null
ip mptcp limits show 2>/dev/null

# Request migration setting when present
sysctl net.ipv4.tcp_migrate_req 2>/dev/null

以所需的最小权限运行命令。ss 输出中的进程名可能需要提升权限，但即使没有权限，监听地址和端口仍然有用。如果完整命令输出包含主机名、内部地址或服务详情，请勿将其粘贴到公开工单中。

接下来，将已安装的软件包与发行版的公告进行比对。在 Debian 上，使用 Debian tracker 和已安装的源码包版本。在 Ubuntu 上，选择确切的内核 flavor 和发行版行。在 Red Hat 上，使用适用的产品状态和勘误。如果厂商声明某个构建已通过向后移植修复，请接受该映射，而不是进行通用的上游比较。

确认系统已启动更新后的内核。软件包安装可能成功，而正在运行的内核仍是旧版本。重启后，将 uname -r 与预期的已安装镜像进行比较。在具有多个启动条目的系统上，验证引导加载程序选择了正确的镜像。在集群中，从每个节点收集结果。

对于外部可达的服务，使用普通连接尝试、负载均衡器配置、防火墙策略和服务发现，从授权的评估主机验证暴露情况。无需传输格式错误的 IP 选项或重复触发竞态的握手。标准 TCP 连接足以确定不受信任的流量能够到达主机。

如果实验室团队需要更深入的保证，请使用相同的厂商镜像构建一次性环境，仅在该环境中启用内核 sanitizer，并运行厂商批准的回归测试。KASAN 文档描述了内核的内存错误检测器。KASAN 对开发和确认很有价值，但其性能开销和改变的内存布局使其不适合作为生产环境的缓解措施，并且可能改变漏洞利用的时序。

安全的验证报告应包含资产标识符、业务服务、网络暴露、MPTCP 状态、相关时的请求迁移状态、软件包版本、正在运行的内核、厂商公告 URL、更新时间戳、重启证据、服务健康结果以及任何临时例外。该记录支持事件响应、审计和后续重新扫描。

教育性生命周期概念验证

这个确定性的 Python 示例对生命周期不变量进行建模，而非漏洞的触发条件。它不发送数据包、不打开套接字、不访问内核内存，也不需要特权或特殊操作系统。布尔对象状态有意替代了真实的分配和释放。它无法确定主机是否存在漏洞或已修补。

def simulate(deferred):
    readers = 1                   # An existing reader holds the object
    allocated = True
    free_requested = True

    if not deferred:
        allocated = False         # Models immediate reclamation
    elif readers == 0:
        allocated = False         # Deferred path must wait

    stale_read_possible = not allocated
    readers -= 1                  # Existing reader exits
    if deferred and free_requested and readers == 0:
        allocated = False
    return stale_read_possible, allocated

assert simulate(False) == (True, False)
assert simulate(True) == (False, False)
print("Immediate reclaim: reader can outlive allocation")
print("Deferred reclaim: existing reader finishes before free")

两条路径最终都会回收该对象。只有立即路径在建模的读取器处于活动状态时将其标记为已回收。真实的 Linux RCU 宽限期比读取器计数器更复杂；此示例在不实现 RCU 或复现内核竞态的情况下讲授顺序要求。安全回归标准是所有预先存在的读取器在回收之前完成。操作标准仍然是厂商的已修复构建映射加上已启动内核的证据。

检测与事件响应

内存破坏利用很少会产生一条决定性的日志记录。检测应结合内核遥测、网络行为、主机状态以及已知的易受攻击版本。若内核崩溃且调用栈接近 ip_options_build()、ip_build_and_send_pkt()、TCP SYN-ACK 构造或套接字销毁，应立即审查。在测试或调试环境中，KASAN 报告若识别出涉及 inet_opt 或 ireq_opt 的释放后使用，尤其值得关注。

审查 journalctl -k、dmesg 归档、崩溃转储和平台串口控制台日志。云实例可能在本地日志刷写前就重启，因此集中式内核日志和提供商控制台历史记录至关重要。如果部署了 kdump，请保留 vmcore、匹配的未剥离内核符号、包元数据和启动配置。如果证据收集是事件计划的一部分，不要立即回收受影响的节点。

网络遥测可以识别出那些以异常选项组合反复发送连接尝试，或持续对 MPTCP 监听器进行重试的客户端。先建立基线。移动网络、有损链路、健康检查和 SYN 代理都可能产生高重传计数。告警应包含目标服务、来源分布、TCP 选项摘要、速率、持续时间以及目标当时是否易受攻击。

Anthropic 描述的一种利用需要在长时间间隔内反复获得机会。因此，来自单一来源或协同来源的长期模式可能比小规模突发更值得关注。攻击者可以分散重试，正常客户端也可能长时间重试。应将该模式视为调查背景，而非特征签名。

端点检测代理对在内核内部发起并执行的利用可见性有限。成功的控制流劫持之后可能创建用户空间进程或更改凭据，但也可能执行混入正常特权活动的操作。应将意外的 root 进程、启动配置更改、新网络连接、模块活动、审计事件和完整性监控告警与内核及网络证据进行关联。

如果怀疑遭到利用，应通过可保留证据的网络控制隔离主机，按照组织的 incident 流程捕获易失状态，轮换主机可能访问的凭据，并调查相邻系统。内核级入侵会使关于用户空间日志和代理完整性的假设失效。在收集证据后，应从可信镜像重建，而不是将软件包更新视为对已受损机器的修复。

检查系统是否暴露了 MPTCP，以及可疑来源是否能够访问它。保留事件时间附近的防火墙、负载均衡器、流、数据包捕获和服务配置。在更改之前，记录确切启动的内核和软件包。如果唯一症状是崩溃，在及时修补的同时，仍应保留意外触发或无关缺陷的可能性。

CVE-2026-98432 缓解措施与内核修复的对比

区分官方变通方案、运营层面的暴露控制和代码修正。Linux 内核 CVE 公告建议更新到当前稳定内核；其“缓解措施”标题并未确立禁用 MPTCP 即可修复该缺陷。

首选修复方案是包含 RCU 回收修复的供应商内核，然后重启进入该内核。使用发行版的常规更新机制及其公告。避免将单个主线提交挑选到企业内核中，除非内核供应商或有经验的内核工程团队负责生成的构建。稳定分支可能需要相关上下文，不受支持的自定义内核会带来未来的补丁和支持风险。

对于整个机群，按公网可达性、MPTCP 使用情况、请求迁移、业务关键性、租户暴露面和供应商支持对系统排序。从面向互联网的节点和终止大量不可信 TCP 的基础设施开始。按滚动顺序修补冗余成员：排空连接、更新、重启、验证正在运行的内核、执行服务检查，并在继续之前将节点重新加入轮换。

在无法立即重启的情况下，降低暴露面。如果组织不使用 MPTCP，则禁用它。将入站 TCP 限制为必需的来源和端口。将管理服务移到经过身份验证的网关之后。移除未使用的公共监听器。在操作安全的情况下，在上游设备上应用速率控制或 SYN 代理。这些是操作建议，需要针对具体服务进行验证。它们可能减少机会，但不能证明所有易受攻击的路径都被阻断，也不能修正过期指针。

仅在服务负责人参与的情况下评估 net.ipv4.tcp_migrate_req 和 reuseport BPF。关闭请求迁移可能减少一条受影响的路径，但可能改变故障转移行为。移除 BPF 程序可能改变流量分布。配置变更需要功能测试和回滚计划。

在边缘阻断所有 IPv4 选项可能减少对依赖选项数据的路径的暴露，但这是一种不完整且可能具有破坏性的控制措施。某些网络使用选项实现特殊行为，并且必须确定过滤器与每条易受攻击路径之间的确切关系。中间盒可能以不同于简单数据包过滤的方式规范化或终止连接。仅将此类控制措施用作临时风险降低手段。

不要依赖容器重启、应用重新部署或用户态库更新。存在漏洞的代码运行在宿主内核中。不要假设 Web 应用防火墙能够看到或理解相关的 IP 和 TCP 握手状态。在 TCP 连接建立后才开始处理的 WAF 位于易受攻击操作的下游。

不受支持的内核面临一个明确的决定。将工作负载迁移到受支持的构建版本，或将其隔离直至更换。本地修补的内核可能适用于专用产品，但这需要具备验证向后移植、测试网络行为、维护符号、发布来源信息并交付未来修复能力的负责人。对大多数组织而言，迁移到供应商支持的内核更安全、更快捷。

对于在授权评估工作流中评估 Penligent 的团队，请将工作范围限定在暴露服务清单、配置证据以及约定工具实际能够执行的变更后检查。不要假设应用测试工作流能够确定内核可利用性或向后移植来源。关闭问题仍需要供应商的确切软件包判定、活动内核以及服务健康证据。

验证修复是否真正生效

更新任务成功并不等同于主机已修复。验证从重启之后开始。使用 uname -r 确认活动内核，并将其映射到供应商的修复软件包。确认更新安装在预期的启动分区上，且引导加载程序在出错后没有回退。在适用的情况下，检查安全启动策略是否接受了该镜像。

从信任边界的双方验证服务。内部健康检查可能通过，而公共监听器缺失；公共检查可能通过，而私有后端路径已损坏。执行正常的 TCP 连接建立、TLS 协商、协议健康检查以及代表性请求。对于 MPTCP 服务，使用组织正常的 MPTCP 功能测试，不要进行恶意时序或内存破坏尝试。

检查内核日志中由此次推出引入的警告。网络修复可能与驱动程序、卸载、BPF、负载均衡和自定义模块产生交互。出现回归并不能成为无限期退回易受攻击内核的理由。遵循供应商的回滚或更换指导，实施临时暴露面缩减，并升级以获取修正后的软件包。

使用能够理解供应商向后移植的工具重新扫描。如果扫描器仍然标记该资产，请附上供应商公告、已安装软件包版本、运行内核证据以及修复来源信息。仅针对确切构建版本抑制确切发现项，并设置到期或审查日期。基于上游版本比较的宽泛例外可能会掩盖后续的易受攻击节点。

对于 Kubernetes 和自动扩缩容集群，既要验证模板，也要验证当前实例。旧的机器镜像可能在初始推出后重新创建易受攻击的节点。更新启动模板、节点镜像、黄金镜像、恢复介质和灾难恢复定义。测试一次扩容事件，并确认新节点启动的是已修复的内核。

对于设备，确认固件升级更改了相关的内核构建版本。保留供应商公告和固件校验和。如果设备供应商尚未发布修复，请记录补偿性控制措施并获取支持声明。避免假设上游补丁之后的固件发布日期会自动包含该补丁。

仅当以下所有条件均满足时，才关闭该修复项：

• 资产及其真实 TCP 暴露面已被记录。
• 供应商确认已安装的构建版本为已修复或不受影响。
• 修复后的内核正在运行，而不仅仅是已安装。
• 所需的重新启动或供应商批准的实时补丁激活已完成。
• 关键服务已通过变更后测试。
• 镜像、模板和替换节点来源已更新。
• 临时缓解措施和例外已有负责人和到期日期。
• 证据已保留，用于事件响应和审计。

常见评估错误

第一个错误是将“Linux”视为单一产品。内核通过发行版、云镜像、嵌入式固件、托管节点镜像和自定义构建进行分发。每种渠道可能携带不同的向后移植补丁。请使用确切的产品渠道。

第二个错误是将 CVSS 评分等同于漏洞利用的普遍程度。9.8 的基础评分描述的是指标模型下的技术严重性。它并不统计易受攻击的主机数量，也不能证明存在活跃利用。较低的发行版特定评分并不能否定针对另一配置的成功实验室利用。风险是严重性、暴露面、证据、资产价值和可用控制措施的综合。

第三个错误是将 Anthropic 的结果解读为普遍适用。该研究证明，一个有能力团队可以在其实验室中远程利用易受攻击的 MPTCP 监听器。它并未确立每个 TCP 监听器都具有相同行为。应利用它来优先处理 MPTCP 和暴露的网络，而不是提出无依据的主张。

第四个错误是宣称 IPv6 普遍安全。主要的子套接字传输问题特定于 IPv4，而上游描述另行指出了涉及 CALIPSO 的 IPv6 迁移问题。双栈系统也继续暴露 IPv4。应评估两种协议并遵循后续供应商修复。

第五个错误是仅扫描应用容器。在常规模型中，容器镜像不携带活动的主机内核。应清点并修补节点。无服务器和托管容器客户应咨询提供商，因为即使客户控制镜像，提供商也控制内核。

第六个错误是将公开利用代码作为生产测试。故意赢得竞争可能导致机器崩溃或被攻陷。一旦供应商确认构建版本易受攻击，这也不会带来多少额外业务价值。安全的配置、软件包、暴露面和补丁后检查可提供可操作的证据，而无需将漏洞武器化。

第七个错误是在安装后未重新启动就关闭工单。除非供应商支持的实时补丁机制覆盖该 CVE，否则旧内核会一直保持活动状态，直到系统启动新镜像。务必记录运行时结果。

MPTCP 和双栈服务的操作注意事项

MPTCP 清点通常不如普通 TCP 清点那么明显，因为管理员可能知道内核支持该协议，却不知道哪个应用程序绑定了 MPTCP 套接字。应从操作系统层开始，然后询问服务负责人他们是显式创建 MPTCP 套接字，还是依赖协商子流的库或代理。检查服务单元、容器能力、套接字激活和部署配置。主机级启用标志是线索，而非完整的服务映射。反过来，能够使用 MPTCP 的应用程序可能在一个环境中回退到普通 TCP，而在另一个环境中主动使用 MPTCP 监听。

对于每个候选服务，记录监听器所绑定的地址族和接口。绑定到通配地址的监听器可能通过比其服务配置所显示的更多接口可达。主机防火墙规则、云安全组、网络策略以及上游负载均衡器的行为都有影响。一份有用的记录应说明不受信任的客户端能否完成到主机 TCP 栈的路径、代理是否先终止客户端连接，以及内部客户端是否在范围内。这样就能将真正隔离的服务与仅仅未出现在公共 DNS 区域中的服务区分开来。

双栈部署应作为两条相连但不同的路径来评估。独立清点 IPv4 和 IPv6 路由、监听器、安全组以及转换设备。上游漏洞的主要所有权转移位于 IPv4 代码中，但仅具有 IPv6 公网入口的主机仍可能通过管理 VLAN、集群覆盖网络、健康检查网络或本地对等体暴露 IPv4。IPv6 数据包在到达易受攻击的主机之前，也可能被转换或代理为单独的 IPv4 连接。决定内核处理内容的是网络架构，而不是“仅 IPv6”之类的产品标签。

在确定依赖关系之前，不要在整个机群中禁用某个协议。MPTCP 可能是有意设计的移动性或路径弹性方案的一部分。仓促的更改可能导致吞吐量损失、破坏故障转移，或以使事件更难诊断的方式改变连接行为。在未使用 MPTCP 的情况下，禁用它是一种合理的临时减少暴露面的措施，但要记录该更改并验证服务并未悄然依赖它。在使用它的情况下，优先进行供应商内核的推广，并应用与服务目标兼容的网络限制。

围绕连接状态规划内核变更

网络端点上的内核维护具有可用性维度。重启会中断已建立的连接，重置某些设备上的连接跟踪状态，并可能改变路由或卸载行为。在更新负载均衡服务之前，确认其余健康节点具有足够容量。一次排空一个节点，等待长寿命会话关闭或达到约定超时，更新内核、重启，并在将其重新加入轮转之前验证就绪状态。如果服务跨多条路径使用 MPTCP，请在变更测试中包含路径故障转移行为。

对于有状态防火墙和网关，确认平台在滚动维护期间如何处理连接同步。节点在进程层面可能健康，但由于路由、隧道状态或 conntrack 同步尚未收敛，可能尚未准备好接受流量。包含来自代表性客户端网络的检查，而不仅仅是本地健康端点。根据供应商支持的滚动回退流程保留先前的镜像可用，但确保任何回退都会触发风险记录中描述的临时暴露控制措施。

协调补丁窗口与内核扩展及树外模块。存储、可观测性、安全和网络代理可能会阻止新内核启动，或在更新后失去功能。验证所需模块具有兼容的构建和签名。重启回旧镜像失败可能会使主机处于易受攻击状态，而监控仅显示包管理器已成功完成。在维护后，对预期修复构建与运行时内核之间的不匹配发出告警。

在云集群中，在替换实例之前更新源镜像。如果自动扩缩组、实例模板、恢复计划或托管节点池仍引用旧镜像，仅对运行中的虚拟机进行一次重启是不够的。在同一网络中测试新启动的替换实例，并确认供应商内核已激活。对于不可变基础设施，修复单元通常是镜像加发布策略，而不是单个主机软件包。

对于 Kubernetes，协调节点驱逐与工作负载中断预算和持久存储约束。先更新一个金丝雀节点，验证 CNI 和服务路由，然后跨区域推进。应检查 DaemonSet 和特权代理的内核版本兼容性。容器重启到已修补节点这一事实并不能证明每个副本都已迁移；收集节点级证据，并将每个工作负载关联回其当前节点。托管 Kubernetes 客户应使用提供商的节点镜像和维护指南，因为提供商拥有内核构建。

使用能经受后续审计的证据

可辩护的修复记录将公告与特定工件关联。保存供应商的 CVE 页面或勘误、软件包名称和修订版本、主机或镜像标识符、更新后的启动时间以及运行中的内核字符串。在供应商发布源软件包状态的地方，包含确切的内核变体和发行版。在产品捆绑自定义内核的地方，包含设备固件版本和供应商声明。这可以防止后续审查者不得不推断一条通用的“Linux 已更新”备注是否覆盖了每个系统。

对于生成 SBOM 的组织，将内核软件包关联到受影响的资产清单，并在可用时保留 VEX 声明。VEX 记录可以说明产品受影响、不受影响、已修复或正在调查，并可以解释该状态的依据。当上游 CVE 数据库显示广泛受影响范围而发行版已向后移植更改时，它特别有用。该声明应保持范围限定在确切的产品版本；在没有证据的情况下，不要将判定复用到不同的内核变体。

保留原始和更新后的扫描结果。前后对比可以显示扫描器识别了供应商软件包修订版本，但它不应取代供应商映射。如果扫描器在更新后继续报告该 CVE，记录该发现是过时的清单结果、不受支持的内核、缺少重启，还是由于向后移植处理导致的误报。没有解释的已关闭发现难以辩护，且容易被错误地重新打开。

为每个例外记录负责人、业务原因、补偿性控制措施、目标日期和明确的重新评估条件。针对暂时不可用的设备的例外，应标明其可接收的网络路径、暴露的服务以及 MPTCP 是否处于活动状态。设置到期时间，而不是让例外永久存在。如果厂商发布修复程序、出现新的漏洞利用证据，或设备的网络边界发生变化，应提前重新评估。

安全团队决策指南

当安全团队收到 CVE 警报时，第一个决策是组织是否拥有相关的内核，而不是漏洞扫描器是否已经产生发现项。查询端点管理、云资产清单、虚拟机镜像、Kubernetes 节点池、网络设备和嵌入式产品记录。搜索内核软件包和受支持的操作系统系列。源代码仓库或运行时标签有助于定位系统，但必须与实际运行的资产进行确认。

第二个决策是哪些资产可以接收不受信任的 TCP 流量。综合使用云流量日志、负载均衡器配置、防火墙策略、服务映射和主机监听器。区分直接互联网流量与被托管代理终止的流量。将受信任的内部网络纳入威胁模型，因为被攻陷的工作站和工作负载可能成为不受信任的来源。仅用于控制平面的设备仍可能拥有可从客户网络访问的数据平面接口。

第三个决策是是否有任何条件会提升优先级。MPTCP 监听器、请求迁移、reuseport BPF、公网暴露、高价值网络角色或缺乏可靠的主机监控，都应使该系统在队列中提前。这些条件并不能证明已被利用。它们标识出更接近已知技术路径、或在被攻陷时具有更高业务影响的配置。

第四个决策是如何验证关闭。确定受支持的修复软件包，部署它，重启进入该版本，测试网络服务，并将最终状态与公告进行比对。不要将计划维护工单或已下载的软件包视为关闭。运行时状态才是关键证据。如果无法应用补丁，应记录有时限的例外，并在组织获得受支持的修复程序期间减少可达路径。

最后，决定是否需要进行事件调查。仅存在有漏洞的公网 MPTCP 监听器就值得紧急修补；但这本身并不能证明已被攻陷。当存在相关的内核故障、可疑的长时间运行连接尝试、无法解释的 root 活动、完整性变更或针对受影响服务的可信威胁情报时，应加入事件响应。保持补丁管理与事件响应相互关联但彼此区分，可避免自满和无依据的入侵声明。

如何准确传达风险

高管更新应说明受影响的资产数量、可达服务数量、MPTCP 暴露情况、修复构建的可用性、推广进度和未解决的例外。将 Linux CNA 的 CVSS 3.1 9.8、Ubuntu 的 CVSS 4.0 8.3 以及当前 Red Hat 产品评估与其来源和指标版本保持关联。决策者需要了解自身环境运行和暴露了什么，以及厂商确认的修复是否实际可用。

一段简洁的技术说明可以这样表述：“Linux IPv4 TCP 请求路径在 IP-options 内存被释放后仍可能使用该内存。上游修复通过 RCU 推迟回收。Anthropic 在受控实验室中针对存在漏洞的 MPTCP 监听器演示了远程 root 代码执行；这并不能确立普遍可利用性。我们优先修补面向互联网且启用 MPTCP 的系统，并在重启后验证正在运行的厂商内核。”这种表述传达了后果、证据、边界和行动，而没有夸大已知信息。

面向客户的沟通应遵循组织的事件和漏洞披露政策。不要仅因为客户系统运行 Linux 就声称其存在漏洞。向平台或厂商询问确切的内核状态，并说明是否有已修复的构建版本。如果重启需要中断服务，应将维护影响与漏洞利用证据分开沟通。

安全团队也应保留不确定性。如果厂商尚未评估自定义镜像，应说明该状态正在调查中，并确定何时会进行审查。如果未发现 MPTCP 监听器，应记录证据和检查时间。如果系统已修补但扫描器未识别出向后移植，应附上厂商证明，并将该发现保持在可审查状态，直到资产数据趋于一致。

常见问题

CVE-2026-98432 是否允许在每台 Linux 服务器上远程获取 root 访问权限？

• 不是。该漏洞可通过网络触达，且一项受控研究利用针对存在漏洞的 MPTCP 监听器实现了 root 命令执行。
• 可利用性取决于内核构建、配置、架构、加固措施、分配器行为、服务暴露情况和竞争条件的可靠性。
• 每个受影响且可触达的主机仍应修补，因为底层缺陷是内核内存损坏。

CVE-2026-98432 在 AlmaLinux 中是否已修复？

• 本次研究未核实明确提及该 CVE 的 AlmaLinux 公告，因此此处状态为未知，而非“不受影响”。
• Check the official AlmaLinux errata for the exact major release and kernel RPM, then confirm the vendor-fixed package is the running kernel.
• Do not copy RHEL status or infer safety from a generic upstream version string.

How do I check Ubuntu CVE-2026-98432 status?

• Use the live Ubuntu CVE tracker and identify the host’s Ubuntu release and exact kernel flavor.
• Package states can differ across generic, cloud, OEM, low-latency, and other kernel variants.
• After installing a fixed package, reboot and verify the active kernel with uname -r.

How do I check CVE-2026-98432 on Proxmox?

• Collect uname -r, pveversion -v and the installed kernel package versions on the host.
• Require an applicable Proxmox announcement, package changelog or support determination; a forum answer is only a lead.
• After updating and rebooting, verify that the confirmed fixed package is the active host kernel.

Does disabling MPTCP fix the vulnerability?

• No. Disabling unused MPTCP may reduce exposure to the demonstrated path, but it is not a vendor-confirmed universal workaround. Verify the state of existing listeners and connections after any supported service change.
• The underlying lifetime error also concerns IPv4 TCP request and child socket handling.
• Install the corrected vendor kernel.

Do containers need to be rebuilt?

• The normal container model shares the host kernel, so the node or host must receive the kernel fix.
• Rebuilding an application image alone does not remediate the issue.
• Update node templates and managed-cluster images so autoscaling does not recreate vulnerable hosts.

How should a backported fix be verified?

• Use the distribution’s CVE page, erratum, package changelog, or VEX statement for the exact product and kernel flavor.
• Confirm the fixed package is installed and that uname -r shows the corresponding running kernel after reboot.
• Do not require the upstream first-fixed version when the vendor documents a backport.

Does CVE-2026-98432 affect every AWS system?

• No blanket AWS determination follows from a Linux version string.
• Assess self-managed EC2 guests through the OS vendor, Amazon Linux images through the exact ALAS package branch, and managed services through their own notices and maintenance guidance.
• A fixed package or new AMI does not prove an existing instance is running the correction.

Final defensive priorities

CVE-2026-98432 is a real kernel object-lifetime failure with a straightforward upstream correction and a demonstrated high-impact research outcome. Its risk should neither be reduced to a theoretical crash nor inflated into a claim that every Linux server is already remotely exploitable. The available evidence supports urgent, targeted action.

Prioritize exposed MPTCP listeners and internet-facing Linux TCP termination points. Use vendor package data rather than generic version matching. Apply the corrected kernel, reboot, validate service operation, update node and appliance templates, and preserve proof of the running fix. Where a change window cannot open immediately, disable unused MPTCP, narrow TCP exposure, and monitor relevant kernel and handshake behavior while scheduling the update.

The most important technical lesson is broader than this CVE: RCU protection is a contract between readers and reclaimers. A reader lock cannot protect an object that a writer returns directly to the allocator. The patch restores that contract by waiting for readers before freeing shared IP options. Verification should restore the operational contract as well: the organization knows which hosts were exposed, which fixed code they run, and whether the service still works after remediation.