CVE-2026-98432: Linux TCP flaw rated 9.8, no Ubuntu or RHEL fix yet

CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP handshake code. The kernel CVE team rated it 9.8 on October 24, and on October 27 Anthropic said one of its internal research models had written a working exploit that gives an unauthenticated remote attacker a root shell. As of October 30, Debian, Oracle Linux, SUSE and Amazon Linux have shipped fixed kernels for at least some releases. Ubuntu and Red Hat Enterprise Linux have not.

A race between a retransmitted SYN and socket teardown

When a TCP connection completes, tcp_v4_syn_recv_sock() hands the request socket's IP options to the new child socket without copying them. If a retransmitted SYN for the same request arrives on another CPU, that CPU can still be reading those options to build a SYNACK when the child socket is freed. The options are freed with a plain kfree() instead of after an RCU grace period, so the SYNACK code reads freed memory.

According to the CVE record's scoring notes, the attacker sends a SYN carrying IPv4 Record Route or Timestamp options, then races a retransmitted SYN against completing and tearing down the same connection. This happens before the application sees a connection, so no login is involved. If the freed memory is reclaimed, the kernel can leak heap contents in the SYNACK, write out of bounds, or panic.

IPv6 is not affected by the main bug because the IPv6 path copies the options.

Affected kernels and upstream fixed versions

The bug dates to Linux 4.4. The fix landed upstream on October 5, the CVE was published October 15, and the fix is in these stable releases:

• 5.10.272
• 5.15.223
• 6.1.190
• 6.6.159
• 6.12.113
• 6.18.56
• 7.2.10
• 7.3-rc7 and later

Severity scores differ by vendor. The kernel CNA scores attack complexity as low because the attacker controls both sides of the race. Red Hat, Oracle and SUSE score it 8.1 with high attack complexity, and Amazon scores it 7.0. Red Hat first published a 5.9 Moderate rating and has since raised it to Important.

Anthropic's exploit requires a Multipath TCP listener

Anthropic's October 27 research post says the exploit works against "Linux servers with a multipath TCP listener." It leaked a kernel pointer to defeat KASLR in 48 minutes, then reached shell command execution about five minutes later. A lost race fails only that handshake without crashing the host, so an attacker can keep retrying. Anthropic did not publish the code, the kernel version, or the configuration it tested. Neither the CVE record nor the kernel patch mentions MPTCP.

MPTCP listeners are more common than most administrators assume. The sysctl net.mptcp.enabled defaults to 1, and since Go 1.24, net.ListenConfig uses MPTCP by default on Linux. A Go service built with a recent toolchain will listen with MPTCP unless the program or kernel turns it off. A server with no MPTCP listener has not been shown to be safe; it only falls outside the configuration Anthropic tested.

No vendor, CISA, or Anthropic has reported exploitation in the wild as of October 30.

Distribution status on October 30

• Debian: fixed. Trixie in linux 6.12.113-1 (DSA-6568-1). Bookworm in linux 6.1.190-1 (DLA-4841-1) and linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1).
• Ubuntu: 22.04, 24.04, 26.04 and 26.10 show fixes in progress, with no Ubuntu Security Notice yet. 16.04, 18.04 and 20.04 are listed as vulnerable. 14.04 is not affected.
• RHEL 8, 9 and 10: affected, no fixed kernel, and Red Hat says no mitigation meets its criteria. RHEL 7 is not affected.
• Oracle Linux: UEK kernels fixed October 16.
• Amazon Linux 2023: the kernel6.18 and kernel6.12 streams have fixes. Amazon Linux 2 is pending.
• SUSE: openSUSE Leap 16.0 and SUSE Linux Micro 6.2 are fixed.

Containers share the host kernel, so rebuilding images does not help. The host or VM kernel has to be replaced and rebooted.

Interim steps for Ubuntu and RHEL servers

First, list services listening with MPTCP:

sudo ss -lnMp

Empty output means none. For Go programs, setting GODEBUG=multipathtcp=0 in the service environment restores pre-1.24 plain TCP behavior. Setting sysctl -w net.mptcp.enabled=0 blocks new MPTCP sockets system-wide but leaves existing listeners open, so restart the affected services and run ss -lnMp again.

Second, drop inbound IPv4 TCP packets that carry IP options, the input the CVE record describes. Legitimate internet traffic almost never sets them. This nftables rule runs before connection tracking and matches IPv4 headers longer than 20 bytes:

sudo nft add table ip cve_2026_98432
sudo nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'
sudo nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop

This is a community mitigation, not a vendor one. The rule does not survive a reboot unless you add it to /etc/nftables.conf or your firewall manager's config. Do not use it on hosts that rely on CIPSO labeling (SELinux or Smack NetLabel), where IP options are normal. sudo nft list table ip cve_2026_98432 shows the drop counter.

Third, limit who can reach your TCP listeners. An origin server that only accepts connections from a CDN or load balancer's address ranges cannot receive the attacker's SYN directly.

Confirming the fix after you reboot

On Debian, uname -v prints the package version of the running kernel; compare it with the fixed versions above. On RHEL-family systems, once the update ships:

rpm -q --changelog kernel-core-$(uname -r) | grep CVE-2026-98432

No output means the running kernel does not have the fix, even if a newer one is installed. On the servers we manage, we are applying the nftables rule and auditing MPTCP listeners until fixed kernels ship, then rebooting as each vendor releases.