Linux Kernel TCP Flaw Rated 9.8 Still Has No Fixed Kernel From Ubuntu or Red Hat as of Oct. 29

A flaw in the Linux kernel's IPv4 TCP handshake code, tracked as CVE-2026-98432, has no fixed kernel yet from Ubuntu or Red Hat Enterprise Linux as of today, Oct. 29. The Linux kernel's CVE team rates it 9.8 out of 10.

The bug is a race condition that can make the kernel read memory it has already freed. The kernel CVE team published the record on Oct. 15 and added the 9.8 score on Oct. 24. The flaw dates to Linux 4.4, so it reaches nearly every maintained kernel line.

How the bug works

When an IPv4 TCP connection completes, the function tcp_v4_syn_recv_sock() hands the IP options stored with the pending request to the new socket. It passes the original, not a copy.

If the new socket is destroyed while another CPU is still using those options to answer a retransmitted connection request, the kernel reads freed memory. The upstream fix, written by Eric Dumazet, makes the kernel wait until other CPUs finish reading before it frees the options. It credits Anthropic researcher Xinyang Ge with the report.

IPv6 is not affected by the main race, because the IPv6 code copies the options. A similar race exists when connection requests migrate between listeners, but that only happens with the net.ipv4.tcp_migrate_req setting turned on or a specific eBPF reuseport program. The kernel documentation lists that setting as off by default.

Anthropic's exploit

Anthropic said on Oct. 27 that an unreleased Claude research model wrote an exploit for the bug. Anthropic says it lets a remote attacker with no credentials run commands as root on Linux servers with a multipath TCP listener. The company calls it a lab test, not a real-world incident.

Anthropic says the exploit works in two stages. It first wins the race repeatedly to leak kernel memory and defeat KASLR, the defense that randomizes where kernel code sits. It then overwrites a callback pointer so the kernel runs a payload the attacker already staged.

A lost race fails only that one connection attempt and does not crash the server, so an attacker can retry. In Anthropic's test, leaking a kernel address took 48 minutes. Reaching root command execution took five more.

Neither the CVE record nor the kernel fix mentions multipath TCP. The link between that feature and this bug comes from Anthropic's post alone. No outside team has publicly reproduced the full chain.

No vendor, CERT or the kernel CVE team has reported exploitation in the wild. As of today the flaw is not in CISA's Known Exploited Vulnerabilities catalog.

Who has patched and who hasn't

Anthropic says the fix was backported to all maintained stable kernel branches. For distribution users, though, that fix only arrives through the vendor's kernel package.

Debian, Oracle Linux, SUSE and Amazon Linux have shipped fixed packages, at least for some kernels. Ubuntu lists every supported release as vulnerable, and its cloud, FIPS and real-time kernels are listed as vulnerable or work in progress.

Red Hat says its fixes are "currently deferred to a future update." Red Hat's own listing says RHEL 7 is not affected because its kernel never received the vulnerable code.

Neither Red Hat nor Ubuntu has given a release date.

A dispute over severity

The 9.8 is not universal. The kernel CVE team's scoring notes assume an attacker who sends a TCP connection request carrying IPv4 Record Route or Timestamp options, then resends it to win the race. The team rates attack complexity low because both sides of the race are "attacker-induced." It says a won race could send adjacent kernel memory back to the attacker, corrupt kernel memory, or crash the system.

The distributions score it lower. Red Hat, Oracle and SUSE give it 8.1 and Amazon gives 7.0, rating the race hard to win. Red Hat's published data ranges from 5.9 to 8.1, and its CVE page rates the flaw Moderate. Ubuntu's page shows the kernel team's 9.8 with a High priority.

As of Oct. 28, the National Vulnerability Database had not added its own score. It showed the kernel team's 9.8.

What administrators can do now

There is no application-level workaround. WAF rules and container isolation do not help, because the bug sits in the host kernel. The fix is a vendor kernel update and a reboot.

One security blog lists fixed upstream stable releases of 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113 and 6.18.56, plus 7.2.10 and 7.3. Distribution kernels often carry the fix under a different package version, so administrators should check the vendor's security notice rather than compare upstream numbers alone.

For Ubuntu and RHEL fleets, the practical step is to inventory IPv4-facing servers and have the update staged for the day the vendor kernel ships. Anyone not running MPTCP listeners should still treat the underlying bug as present, since the CVE record describes a general IPv4 TCP flaw.

What remains open is timing. Canonical and Red Hat have not said when fixed kernels will land, and Red Hat describes a deferred fix as not guaranteed. The NVD has also yet to publish an independent score.