Linux's October 2026 TCP Use-After-Free: CVE-2026-98432

#Overview

Linux's stable kernels shipped a fix on October 11 and 15, 2026 for CVE-2026-98432, a use-after-free in the IPv4 TCP handshake that a remote, unauthenticated peer can reach. The kernel's own CVE Numbering Authority (CNA) scores it CVSS 3.1 9.8, Critical. The fixed 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, and the bug goes back to Linux 4.4. The upstream fix is a four-line change, but most servers run a distribution's kernel, and as of 11:00 AM CDT, October 29, Ubuntu's tracker still reads "Vulnerable" for its kernel on every release, and Red Hat lists RHEL 8, 9, and 10 as affected with no fix.

Why it's urgent: the bug sits in code every Linux server runs when it accepts an IPv4 TCP connection, before any application sees the connection. Anthropic, whose researcher reported it, 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. See the timeline.

#Key facts

#Who is affected

Any Linux kernel from 4.4 on that lacks the fix, whether it serves the network directly or hosts containers: a container runs on the host's kernel, so a new image doesn't change anything. IPv6 connections aren't affected by the main issue; the commit says "IPv6 is not affected by the first issue."

#Distribution status

Distribution kernels carry backported fixes under their own version numbers, so check the tracker, not the upstream number. As of 11:00 AM CDT, October 29:

• Ubuntu: the tracker 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: RHEL 8, 9, and 10 and OpenShift Container Platform 4 are listed as affected, with no fix; RHEL 6 and 7 aren't affected (CVE page). Red Hat says mitigation "is either not available or the currently available options do not meet the Red Hat Product Security criteria."
• Debian: fixed 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 (tracker).
• SUSE: rated 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 (CVE page).

#How the vulnerability works

When a Linux server accepts a TCP connection, the kernel tracks the half-open handshake in a lightweight "request socket," then creates a full socket once the handshake completes. If the connecting peer's IPv4 header carried options, the kernel keeps them to echo in its replies. The bug: the kernel handed those saved options from the request socket to the new connection without copying them, then freed them immediately when the connection went away, while another CPU could still be reading them to build a handshake reply. Reading freed kernel memory is a use-after-free.

The peer needs no login, and it all happens inside the kernel's handshake handling, before any application code runs. The CNA's scoring 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 says a lost race "only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed."

#The fix

Eric Dumazet's commit, "ipv4: free inet_opt and ireq_opt after an RCU grace period," changes two plain kfree() calls to kfree_rcu(), which waits until every reader has finished with the memory before freeing it. Other code paths that replace these options already did that. The commit also fixes the same problem in request-socket migration (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program), and says a related IPv6 case "will be addressed in a separate patch."

#Which servers are exposed

• Every Linux host that accepts IPv4 TCP connections on an affected kernel: web servers, SSH, databases, load balancers, and Kubernetes nodes. The CNA's notes say the vulnerable path runs "during the TCP handshake, before application authentication."
• Hosts with a multipath TCP (MPTCP) listener first. That's the setup Anthropic's working exploit needs: "Linux servers with a multipath TCP listener." Anthropic hasn't said why that listener matters, and the CVE record doesn't mention MPTCP. A server has one only if an application opens an MPTCP socket; the check is below.

Red Hat rates the bug lower than the CNA. It scores the attack complexity as High (CVSS 8.1) and describes the result as mainly a crash "or potential memory corruption." Anthropic's lab exploit shows a remote root shell on at least one configuration, so a lower rating isn't a reason to wait.

#How to check your systems

#Check the kernel

1uname -r                             # the running kernel2uname -v                             # Debian: the package version running3dpkg -l 'linux-image*' | grep ^ii    # Debian/Ubuntu: installed kernel packages4rpm -q kernel                        # RHEL and derivatives: installed kernels5needs-restarting -r                  # RHEL (dnf-utils): is a reboot needed?

Compare the result with your distribution's status above, not with the upstream version. If the installed kernel is newer than the running one, the fix isn't active until you reboot. Run these on container hosts and Kubernetes nodes, not inside containers: a container reports the host's kernel. We ran them on a Debian 12 host and in a Rocky Linux 9 container.

#Check for multipath TCP listeners

1ss -Mlnp                   # MPTCP listening sockets and the processes that own them2sysctl net.mptcp.enabled   # 1 means applications may open MPTCP sockets

ss -M lists only MPTCP sockets, so an empty result means no MPTCP listener. net.mptcp.enabled = 1 alone doesn't create one: an application has to open an MPTCP socket. We tested both with iproute2 6.1 in a Debian 12 container, where ss -Mlnp listed a test MPTCP listener and skipped a plain TCP one beside it.

#How to fix

#Update the kernel and reboot

Install your distribution's fixed kernel as soon as it ships, then reboot: a kernel update doesn't take effect until the machine boots into it. Reboot container hosts and Kubernetes nodes too. Appliances and cloud images that bundle a kernel need their vendor's update.

On Debian and on SUSE Linux Enterprise Server 16.0 and the 15 LTSS releases, the fix is out. On Ubuntu and RHEL, it isn't yet, as of 11:00 AM CDT, October 29. Watch the trackers linked above. Running a self-built kernel? Move to the fixed stable release for its line.

#If you can't patch yet

Red Hat publishes no mitigation. The following is Atlas's interim recommendation, based on the CNA's scoring notes, which say the attacking peer supplies IPv4 Record Route or Timestamp options in its SYN. TCP traffic almost never carries IPv4 options legitimately, so dropping TCP packets that have them should cost nothing:

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

ip hdrlength gt 5 matches any IPv4 header longer than the 20-byte minimum, which only options produce. The rule runs before connection tracking and doesn't touch IPv6 or non-TCP traffic. We tested it in a Debian 12 container: it dropped a SYN carrying a Record Route option, and ordinary TCP connections still worked. We haven't tested it against an exploit, and it doesn't fix the kernel. It lasts until reboot, which is fine if the reboot is into a fixed kernel; remove it with nft delete table ip cve_2026_98432. If your edge firewall can drop IPv4 packets with options, doing it there protects every host behind it.

Until then, keep MPTCP listeners off the internet, and put the hosts that have one at the top of the patch list.

#Timeline and exploitation status

All times are CDT (UTC−5).

Exploitation status. Anthropic says Claude wrote the exploit "after initial prompting," that it runs "arbitrary commands as root, without any credentials or user interaction" on servers with a multipath TCP listener, and that in its proof of concept "it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution." Anthropic hasn't published the exploit. Its disclosure policy gives developers 90 days to patch and a further 45 days before Anthropic discusses details beyond a public advisory. GitHub repositories referencing the CVE appeared on October 29, one describing itself as an audit script. We haven't tested any of them, and we aren't linking them.

#Updates to this post

We'll revise this post and mark it updated when any of these change: fixed kernels from Ubuntu or Red Hat; NVD's analysis; a KEV listing or any report of exploitation; the separate IPv6 fix.

#Get help

If the hard part is knowing which hosts, nodes, and appliances run which kernel, and which of them can reboot this week, our advisors can help plan it.

The bug is reachable through any listening TCP port, so it helps to know which ones the internet can see. Our free external audit checks the domains and public IPs you verify for exposed services, publicly visible software versions with known CVEs, TLS, email security, DNS, and HTTP headers.

It's the second Linux kernel fix this month that only takes effect after a reboot. The other, Fragnesia, is being chained with PHP2Shell to get root.

#Sources

• Linux kernel: fix commit e3f33b0 · patch on lore · stable commits for 7.2.10, 6.18.56, 6.12.113, 6.6.159, 6.1.190, 5.15.223, and 5.10.272 · kernel.org releases
• CVE records: cve.org · NVD
• Distributions: Ubuntu · Red Hat · Debian · SUSE
• Research: Anthropic: Discovering and exploiting vulnerabilities in critical, real-world software with Claude · Anthropic's coordinated vulnerability disclosure policy