Linux TCP Bug CVE-2026-98432: 9.8 Severity, Ubuntu Still Unpatched

What is CVE-2026-98432 and why is it rated 9.8?

It's a use-after-free in the Linux kernel's IPv4 TCP handshake code that any remote peer can trigger without credentials.

The bug lives in the code every Linux server runs when it accepts an IPv4 TCP connection, before any application sees it. When a peer's IPv4 header carries options, the kernel saves them in a request socket and later hands them to the full socket without copying. If the connection goes away, those options are freed immediately while another CPU may still be reading them to build a reply. That's a classic use-after-free.

The kernel's own CVE Numbering Authority scored it CVSS 3.1 9.8, Critical. The CNA notes say the stale data can leak kernel heap memory back to the peer, steer kernel writes out of bounds, or crash the machine. Anthropic, whose researcher reported the bug, says its Claude model wrote a working proof-of-concept exploit that runs commands as root on "Linux servers with a multipath TCP listener," with no credentials.

Eric Dumazet's upstream fix is a four-line change: it swaps two plain kfree() calls for kfree_rcu(), which waits until every reader has finished with the memory before freeing it. The same pattern was already used elsewhere in the kernel. The commit also fixes the same problem in request-socket migration and says a related IPv6 case "will be addressed in a separate patch."

Which Linux distributions are patched?

The upstream stable kernels are fixed, but distribution kernels carry backported fixes under their own version numbers, so check your distro's tracker, not the upstream version.

The fixed 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. The bug goes back to Linux 4.4.

As of 8:00 PM CDT on October 29, Ubuntu's tracker still lists the linux package as "Vulnerable" on every release. On 26.10, 26.04, 24.04, and 22.04 it adds "work in progress" in 7.3.0-10.10, 7.0.0-43.43, 6.8.0-149.149, and 5.15.0-203.213; 20.04, 18.04, and 16.04 show only "Vulnerable." Many cloud and hardware-enablement kernels are listed the same way, and no Ubuntu Security Notice has been published.

Red Hat lists RHEL 8, 9, and 10 and OpenShift Container Platform 4 as affected, with no fix. RHEL 6 and 7 aren't affected. Red Hat says mitigation "is either not available or the currently available options do not meet the Red Hat Product Security criteria."

Debian has fixes in 12 "bookworm" (6.1.190-1, DLA-4841-1, and linux-6.12 6.12.113-1~deb12u1, DLA-4850-1), 13 "trixie" (6.12.113-1, DSA-6568-1), and unstable. SUSE rates it important: SUSE Linux Enterprise Server 16.0 (kernel-default 6.12.0-160000.40.1) and the 15 SP4, SP5, and SP6 LTSS kernels are fixed; 15 SP7 is in progress, and openSUSE Leap 15.6 and 16.0 are listed as affected.

Oracle Linux rates it Important, CVSS 3.1 8.1. Unbreakable Enterprise Kernel errata for Oracle Linux 7, 8, 9, and 10 came out October 16 (ELSA-2026-500397, ELSA-2026-500398, ELSA-2026-500399). Amazon Linux rates it Important, CVSS 3.1 8.1: on Amazon Linux 2023, kernel6.18 is fixed (ALAS2023-2026-3251, October 24) and kernel6.12 is fixed (ALAS2023-2026-3335, October 29). The default kernel package and every Amazon Linux 2 kernel are "Pending Fix."

Who is at risk and how do you check your server?

Every Linux host that accepts IPv4 TCP connections on an affected kernel is exposed, including web servers, SSH, databases, load balancers, and Kubernetes nodes.

The vulnerable path runs during the TCP handshake, before application authentication, so a firewall rule that blocks new connections is the only network-level defense. Containers don't help: a container runs on the host's kernel, so a new image changes nothing.

Hosts with a multipath TCP (MPTCP) listener are the first concern. That's the setup Anthropic's working exploit needs, though Anthropic hasn't said why the listener matters and the CVE record doesn't mention MPTCP. A server has one only if an application opens an MPTCP socket.

To check for MPTCP listeners, run `ss -M` on the host (not inside a container). An empty result means no MPTCP listener. `net.mptcp.enabled = 1` alone doesn't create one. Also verify your running kernel against your distribution's tracker: if the installed kernel is newer than the running one, the fix isn't active until you reboot.

This isn't the first time a kernel-level flaw has exposed the gap between upstream patches and distribution kernels. Similar delays have shown up in other high-profile incidents, such as the PHP2SHELL attacks on Palo Alto firewalls, where patching speed made the difference.

• Run `ss -M` on container hosts and Kubernetes nodes, not inside containers.
• Check your distribution's CVE tracker for the exact kernel package version.
• Reboot after installing a fixed kernel; a newer installed kernel does nothing until then.

How serious is it, really?

Red Hat rates it lower than the CNA, but Anthropic's lab exploit shows a remote root shell on at least one configuration.

Red Hat scores the attack complexity as High (CVSS 8.1) and describes the result as mainly a crash "or potential memory corruption." That's a meaningful difference from the CNA's 9.8, and it may explain why RHEL fixes aren't out yet.

But a lower rating isn't a reason to wait. Anthropic says a lost race "only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed." A remote, unauthenticated attacker who can retry indefinitely is a serious problem, even if each attempt is unreliable.

The bigger issue is timing: the technical details are now public, and the exploit is described in enough detail to reproduce. Every hour that a production kernel remains unpatched is an hour an attacker can use.

What it means for you

If you run Linux servers in the US, UK, or EU, check your distribution's status now. Debian, SUSE, Oracle Linux, and Amazon Linux 2023 have fixes; Ubuntu and Red Hat do not, as of October 29. Cloud providers that use their own kernels may have patched silently, so check your provider's security bulletin.

For Ubuntu and RHEL users, the practical advice is to apply the vendor kernel as soon as it ships and reboot. In the meantime, restrict inbound IPv4 TCP where possible and monitor for unusual crashes or memory corruption. There is no official mitigation from Red Hat.

The patch is four lines; the wait is the problem. If you run Linux, check your distribution's tracker, apply the kernel update when it lands, and reboot. For Ubuntu and RHEL users, that means watching for a security notice in the coming days.