CVE-2026-98432: The CVSS War Over the Linux Kernel TCP Vulnerability

A use-after-free in the Linux kernel's IPv4 TCP code, published on October 15, 2026 under identifier CVE-2026-98432, has produced an unusual fracture in risk scoring systems. The Linux Kernel CVE Team assigns the flaw a score of 9.8 out of 10, classifying it as critical. Red Hat, within the same timeframe, reports a range between 5.9 and 8.1. The discrepancy is not academic: as of October 29, 2026, Ubuntu and the enterprise distribution Red Hat Enterprise Linux remain without released patches, while Debian, Oracle Linux, SUSE, and Amazon Linux have already shipped corrective packages.

The Mechanism: A Race Condition in the IPv4 Three-Way Handshake

The flaw resides in the function tcp_v4_syn_recv_sock(), a central element in handling incoming TCP connections. During the three-way handshake, the kernel transfers ownership of the pointer ireq->ireq_opt to the child socket without copying it. If another processing core simultaneously processes a retransmitted SYN referring to the same request socket, the race condition allows reading of already-freed memory.

The immediate consequence is a use-after-free in the operating system's most frequent network path. The fix, applied on October 5, 2026, replaces direct calls to kfree() with kfree_rcu() in inet_sock_destruct() and tcp_v4_reqsk_destructor(), guaranteeing an RCU grace period that prevents access to deallocated structures. The official CVE record confirms that IPv6 is not affected: tcp_v6_syn_recv_sock() duplicates the options instead of transferring their ownership.

The CVSS Split: 9.8 vs. 8.1 vs. 5.9

The kernel team's CVSS:3.1 vector — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — indicates remote attack, low complexity, no privileges required, no user interaction, and full impact on confidentiality, integrity, and availability. Red Hat, in the machine-readable advisory file, modifies a single parameter: AC:H (attack complexity high), reducing the score to 8.1. On the dedicated CVE page, however, a further reduction to 5.9 appears with vector C:N/I:N/A:H, limiting impact to availability only.

Amazon Linux sets its own score at 7.0 for AL2023. The variability does not stem from differing interpretations of the mechanism — all sources converge on the race condition in tcp_v4_syn_recv_sock() — but from corporate criteria on the likelihood of successful exploitation in real-world conditions and on the definition of impact. For those managing infrastructure at scale, the operational consequence is paralysis in prioritization: the kernel team's 9.8 demands immediate action, while Red Hat's 5.9 suggests deferral.

"Red Hat, Amazon, Oracle, and SUSE score the flaw between 5.9 and 8.1, lower than the kernel team's 9.8." — The Hacker News

Patch Status: Two Speeds in the Linux World

The distribution of fixes maps a fragmented geography. Debian, Oracle Linux, SUSE, and Amazon Linux have completed their releases. Ubuntu, with High priority on all supported releases (22.04 LTS, 24.04 LTS, 26.04 LTS, 26.10), reports status "Work in progress" or "None released" as of October 29, 2026. Red Hat Enterprise Linux 8, 9, 10, and OpenShift 4 show status "Fix deferred" with no availability date indicated.

The time gap between the upstream fix (October 5) and the absence of enterprise packages (at least 24 days) exposes a class of systems vulnerable by definition: servers with publicly listening TCP services that cannot recompile the kernel themselves. For cloud providers and Kubernetes clusters, where the kernel is shared across all containers, the lack of a patch means every pod exposed to the network inherits the attack surface of the underlying system.

Anthropic's AI Exploit: Claim Without Verifiable Code

On October 27, 2026, Anthropic published a statement that its model Claude, in response to an initial prompt, generated a working exploit to achieve command execution as root. According to the source, the model took 48 minutes to leak the kernel address and an additional five minutes to complete the exploit chain. The technology cited by Anthropic is MPTCP (Multipath TCP), an extension not mentioned in the CVE record or the fix commit.

This discrepancy is documented explicitly by the primary source: "Neither the CVE record nor the fix mentions multipath TCP (MPTCP). The link between that feature and this bug comes from Anthropic's post." No source code has been published, no tested kernel version has been specified, and no independent reproduction is currently available. As of October 29, 2026, no vendor advisory, no CVE record, and no CISA KEV listing reports in-the-wild exploitation.

What to Do Now

For organizations operating on distributions with available patches (Debian, SUSE, Oracle Linux, Amazon Linux), the source indicates updating the kernel package as the only documented path. For Ubuntu and RHEL environments, the source does not specify alternative corrective actions beyond waiting for the official release.

Red Hat has explicitly stated that "mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability." This constraint, published in the official advisory, limits operational options for enterprise installations.

The source does not list alternative countermeasures such as blocking IP options, disabling MPTCP, or firewall configurations, and the inclusion of such measures in the decision-making process is not supported by available data. The lack of mitigations acceptable by vendor criteria implies that rebooting onto a corrected kernel remains the only documented full-resolution scenario.

For cloud providers and Kubernetes platforms, the shared kernel structure across all workloads amplifies dependence on the underlying distribution's release cycle, without the source indicating technical shortcuts to isolate risk at the individual container level.

Why the CVSS Divergence Matters More Than the Single Number

The CVE-2026-98432 case exemplifies a systemic problem in open-source vulnerability governance. The kernel team evaluates the flaw from the source-code perspective: the race condition is theoretically exploitable, the vector is remote, the impact is total. Red Hat introduces contextual filters: attack complexity, system stability under patching, operational feasibility. Both calculations are correct within their own boundaries, but their overlap on risk-management systems generates fragmentation.

For the security lead who must present a priority to the board, the fragmentation becomes a problem of translatability. The 9.8 triggers incident-response procedures; the 5.9 does not. The absence of in-the-wild exploits feeds caution, but that same absence does not prove impossibility. Anthropic's statement, lacking independent verification, adds noise without increasing knowledge.

FAQ

Why does the CVSS score differ between the kernel team and Red Hat?

The kernel team applies the theoretical vector of the flaw in the source code. Red Hat introduces the AC:H (attack complexity high) parameter and, on the CVE page, limits impact to availability (C:N/I:N/A:H), progressively reducing the score based on proprietary operational criteria.

Is Anthropic's exploit reproducible?

No source code has been published, no tested kernel version has been indicated, and the MPTCP technology cited by Anthropic does not appear in the CVE record or the fix commit. The source reports no independent reproductions as of October 29, 2026.

Is IPv6 vulnerable in the same way?

No. According to the official CVE record, tcp_v6_syn_recv_sock() duplicates the options instead of transferring their ownership, eliminating the race condition that generates the use-after-free in the IPv4 path.

Sources

• thehackernews.com
• access.redhat.com
• ubuntu.com
• app.opencve.io
• nolimitcloud.eu
• cve.org
• cve.org
• security.access.redhat.com
• msrc.microsoft.com