Critical Linux TCP handshake flaw (CVE-2026-98432) fixed upstream, Ubuntu and RHEL still exposed

What happened

The Linux kernel project has shipped fixes for CVE-2026-98432, a use-after-free in the IPv4 TCP handshake path that a remote, unauthenticated peer can trigger. According to Atlas, which traced the upstream commits and distribution trackers, the kernel's own CVE Numbering Authority rates the flaw Critical with a CVSS 3.1 score of 9.8. The bug has been present since Linux 4.4, and the patched upstream releases are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3, arriving between October 11 and 18, 2026. The CVE record was published on cve.org on October 15; Atlas notes that NVD still listed it as merely received, with no analysis, as of the evening of October 29.

The vulnerability was reported by Xinyang Ge of Anthropic, and the fix — a two-file, four-line change by Eric Dumazet, reviewed by Kuniyuki Iwashima — landed in early October. Anthropic says its Claude model built a working proof-of-concept that executes commands as root, with no credentials, against servers running a multipath TCP (MPTCP) listener. The exploit has not been published, and neither Anthropic nor the CVE record explains why an MPTCP listener is required.

How the bug works

When a server accepts an IPv4 TCP connection, the kernel first tracks the half-open handshake in a lightweight request socket, then creates a full socket once the handshake completes. If the connecting peer's IP header carried options, the kernel kept a copy so it could echo them in replies. As Atlas explains, the kernel handed that saved option data from the request socket to the new connection without copying it, then freed it as soon as the connection went away — while another CPU could still be reading the memory to build a handshake reply. That race is the use-after-free.

All of this happens inside the kernel during the handshake, before any application code or authentication runs. The CNA's scoring notes say the consequences range from disclosing kernel heap contents to the remote peer, to steering kernel writes out of bounds, to a crash. Anthropic adds that a lost race merely fails that one handshake rather than crashing the system, so a persistent attacker can retry indefinitely. Per the fix commit, IPv6 is not affected by this particular issue.

The fix

Dumazet's commit, "ipv4: free inet_opt and ireq_opt after an RCU grace period," replaces two plain kfree() calls with kfree_rcu(), which waits until all readers have finished before releasing the memory — something equivalent code paths already did. The same patch fixes an identical problem in request-socket migration, reachable via net.ipv4.tcp_migrate_req=1 or a BPF socket-migration program, and notes that a related IPv6 case will be handled separately.

Distribution status

Distribution kernels backport fixes under their own version numbers, so operators should check trackers rather than upstream versions. As of 8:00 PM CDT on October 29, Atlas's survey found:

• Debian: fixed in bookworm (12) via two advisories, in trixie (13), and in unstable.
• Ubuntu: every release still listed as vulnerable, with fixes in progress on some kernels and no Security Notice yet published.
• Red Hat: RHEL 8, 9 and 10 plus OpenShift Container Platform 4 affected with no fix; Red Hat states available mitigations do not meet its product security criteria.
• SUSE: SLES 16.0 and the 15 SP4–SP6 LTSS kernels fixed, 15 SP7 in progress, openSUSE Leap 15.6 and 16.0 still affected.
• Oracle: Unbreakable Enterprise Kernel errata issued October 16 for Oracle Linux 7 through 10.
• Amazon: Amazon Linux 2023's kernel6.18 and kernel6.12 fixed; Amazon Linux 2 and AL2023's default kernel still pending.

Vendors disagree on severity. Red Hat, Oracle and Amazon rate it Important at CVSS 8.1 with high attack complexity, SUSE calls it important, and Ubuntu rates it High. Red Hat describes the impact as primarily a denial of service or potential memory corruption — but Anthropic's demonstrated root exploit shows the lower scores are not a reason to delay patching.

How to check your systems

Run checks on the host itself, not inside containers: a container runs on the host's kernel, so pulling a new image changes nothing. Compare the running kernel against your distribution's status above, and remember a newer installed kernel does nothing until you reboot. The command ss -M lists MPTCP sockets, so an empty result means no MPTCP listener — the configuration the known exploit targets. Beyond that, any host accepting IPv4 TCP connections is on the vulnerable path: web servers, SSH, databases, load balancers and Kubernetes nodes alike.

Why it matters

This is a pre-authentication kernel flaw reachable over the internet's most ubiquitous protocol, on code every Linux server executes. The upstream fix is trivially small, but the real exposure window is the distribution gap: as of this reporting, Ubuntu, RHEL and Amazon's default kernels — a large share of deployed servers — remain unpatched while a working remote-root exploit exists. Container operators are equally exposed, since hosts share one kernel. The story also adds a concrete data point to the debate over AI-assisted security research: an AI-generated exploit for a kernel bug is no longer hypothetical.