Linux CVE-2026-98432 TCP Use-After-Free: CVSS 9.8, Fixed Kernels, and Distribution Status

CVE-2026-98432 is a Linux kernel use-after-free in IPv4 TCP handshake handling that a remote, unauthenticated peer can reach before any application sees the connection. The Linux kernel CNA scores it CVSS 3.1 9.8, Critical, and upstream stable kernels shipped a fix in October 2026, but major distribution kernels including Ubuntu and Red Hat Enterprise Linux remained unfixed as of October 29, 2026.

What happened

Linux stable kernels shipped a fix for CVE-2026-98432 on October 11 and October 15, 2026. The bug is a use-after-free of IPv4 option data during the TCP handshake. The upstream fix is small: Eric Dumazet's commit, "ipv4: free inet_opt and ireq_opt after an RCU grace period," replaces plain kfree() calls with kfree_rcu() so memory is not freed while another CPU may still be reading it.

The bug goes back to Linux 4.4. 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 CVE record was published on October 15, 2026. Xinyang Ge of Anthropic is credited as the reporter; Eric Dumazet fixed it and Kuniyuki Iwashima reviewed the fix.

Why it matters

The vulnerable path runs inside the kernel's TCP handshake handling, before application authentication. Any Linux host from 4.4 onward that accepts IPv4 TCP connections and lacks the fix is exposed, including container hosts and Kubernetes nodes, because containers run on the host kernel.

Anthropic 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. Anthropic has not published the exploit. The CNA's scoring notes say the stale data can disclose kernel heap contents to the remote peer, cause kernel memory corruption, or crash the machine. Red Hat describes the impact more conservatively as "primarily results in a system crash leading to a Denial of Service (DoS) or potential memory corruption."

Key facts

Field	Detail
CVE	CVE-2026-98432, "ipv4: free inet_opt and ireq_opt after an RCU grace period"
Severity	Critical, CVSS 3.1 9.8 from the Linux kernel CNA (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
Other scores	Red Hat: Important, CVSS 3.1 8.1 with High attack complexity. SUSE: important. Ubuntu: High. Oracle and Amazon: Important, CVSS 3.1 8.1.
Weakness	Use-after-free of IPv4 option data during the TCP handshake
Impact	Kernel heap disclosure to the remote peer, kernel memory corruption, or crash
Fixed upstream	7.2.10 and 6.18.56 on October 11; 6.12.113, 6.6.159, 6.1.190, 5.15.223, and 5.10.272 on October 15; 7.3 on October 18
No upstream fix	Branches that reached end-of-life before 5.10
Proof of concept	Anthropic says Claude built a remote root exploit for servers with a multipath TCP listener; it has not published the exploit
NVD status	Listed as "Received" with no NVD analysis as of 8:00 PM CDT, October 29, 2026
CISA KEV	Not listed as of 8:00 PM CDT, October 29, 2026

How the vulnerability works

When a Linux server accepts a TCP connection, the kernel tracks the half-open handshake in a request socket, then creates a full socket once the handshake completes. If the connecting peer's IPv4 header carries options, the kernel saves them to echo in replies. The bug is that 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.

The peer needs no login, and the vulnerable code runs before application code. 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 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). The commit says a related IPv6 case "will be addressed in a separate patch." The main issue does not affect IPv6 connections.

Which kernels are fixed

Release line	Status on October 29, 2026	Fixed in	Released
7.3	Mainline	7.3, from 7.3-rc7	October 18, 2026
7.2	Stable	7.2.10	October 11, 2026
6.18	Longterm	6.18.56	October 11, 2026
6.12	Longterm	6.12.113	October 15, 2026
6.6	Longterm	6.6.159	October 15, 2026
6.1	Longterm	6.1.190	October 15, 2026
5.15	Longterm	5.15.223	October 15, 2026
5.10	Longterm	5.10.272	October 15, 2026
4.4 to 5.4	End-of-life upstream	Distribution fixes only	Not applicable

A Hacker News commenter listed 5.15.225 rather than 5.15.223 for the 5.15 line. Administrators should verify the exact fixed version against the stable tree or their distribution's kernel package rather than relying on a single list.

Distribution status as of October 29, 2026

Distribution kernels carry backported fixes under their own version numbers, so the upstream version is not the right check. As of 8:00 PM CDT on October 29, 2026:

Distribution	Status
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." No Ubuntu Security Notice had 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 are not affected. 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 Debian 12 "bookworm" (6.1.190-1, DLA-4841-1, and linux-6.12 6.12.113-1~deb12u1, DLA-4850-1), Debian 13 "trixie" (6.12.113-1, DSA-6568-1), and unstable.
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. openSUSE Leap 15.6 and 16.0 are listed as affected.
Oracle Linux	Rated 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, and ELSA-2026-500399. The page lists only the UEK kernels.
Amazon Linux	Rated 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."

Exploitation status and the multipath TCP question

Anthropic's Frontier Red Team described the exploit on October 27, 2026. Anthropic says Claude wrote it "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 has not published the exploit. Its coordinated disclosure policy gives developers 90 days to patch and a further 45 days before Anthropic discusses details beyond a public advisory.

By 8:00 PM CDT on October 29, eight GitHub repositories referenced the CVE. Most described themselves as audit or mitigation tooling, including an Ansible role and a livepatch for AlmaLinux and Rocky Linux. One repository, created at 7:22 PM, said it included a race trigger. The CVE was not in CISA's Known Exploited Vulnerabilities catalog at that time.

A central dispute in the Hacker News discussion is whether multipath TCP is required. The source article says Anthropic's working exploit targets "Linux servers with a multipath TCP listener" and does not explain why that listener matters; the CVE record does not mention MPTCP. Commenters pushed back on treating MPTCP as a requirement.

"MPTCP is not a requirement, it is a generic use-after-free."

— peanut-walrus

"This saddens me since MPTCP is quite useful and not the cause of the bug, just a way to ease exploitation (probably simpler heap massaging? Way over my head). Anyway, upgrade, but don't block MPTCP; no exploit is available, and it's just as likely someone finds another path before Anthropic releases theirs."

— Aissen

A practical check for MPTCP listeners is ss -M, which lists only MPTCP sockets. An empty result means no MPTCP listener. Setting net.mptcp.enabled = 1 alone does not create one; an application has to open an MPTCP socket. The source article tested this with iproute2 6.1 in a Debian 12 container, where ss -Mlnp listed a test MPTCP listener and skipped a plain TCP listener beside it.

How to check and mitigate

Check the running kernel, not just the installed package. If the installed kernel is newer than the running one, the fix is not active until reboot. Run checks on container hosts and Kubernetes nodes, not inside containers, because a container reports the host's kernel.

For hosts that cannot be patched immediately, the source article recommends dropping TCP packets that carry IPv4 options. TCP traffic almost never carries IPv4 options legitimately. The rule ip hdrlength gt 5 matches any IPv4 header longer than the 20-byte minimum, which only options produce. The source says the rule runs before connection tracking and does not touch IPv6 or non-TCP traffic. It was tested in a Debian 12 container: it dropped a SYN carrying a Record Route option while ordinary TCP connections still worked. The source has not tested the rule against an exploit, and the rule does not fix the kernel. It lasts until reboot, which is acceptable if the reboot is into a fixed kernel; it can be removed with nft delete table ip cve_2026_98432.

Commenters added important caveats. Red Hat says dropping packets with IP options helps but is not a full mitigation. One commenter reported that NetLabel/CIPSO configurations using SELinux or Smack with a CIPSOV4 mapping may create the same conditions as a packet with IP options, so dropping IPv4 options might not fully mitigate those systems. Another commenter reported that an edge router rule to drop inbound IP packets with options had a hit count of zero and was difficult to test because upstream networks already filtered such packets.

"At least according to Red Hat, dropping packets with IP options yourself helps, but is not a full mitigation."

— peanut-walrus

"Also appears that using NetLabel/CIPSO (SELinux or Smack with a CIPSOV4 mapping) creates the same conditions that a packet with IP options would. If you're using these, it might mean that dropping IPv4 packets with IP options might not fully mitigate."

— jamilbk

One commenter said a UFW filter rejecting IPv4 packets with oversized headers broke something essential and had to be disabled. That is a caution against deploying untested firewall rules broadly without a rollback plan.

Single-core systems and consumer routers

A commenter noted that successful exploitation requires multiple CPU cores to process packets. Systems with a single core, or with packet processing pinned to a single core, are not affected according to that commenter. The source article does not make this claim, so it should be treated as a community observation rather than an official statement.

"If this requires a multi-core system to exploit, it's good news for most of the consumer routers that will never get updates. Saved by cheap single-core hardware."

— mrob

Commenters also asked about desktop Linux, consumer modems and routers, IoT devices, and OpenWrt. The source article focuses on servers and does not answer those questions. The general rule from the source is that any Linux kernel from 4.4 onward that lacks the fix and accepts IPv4 TCP connections is exposed, but appliances and cloud images need their vendor's update.

Cloud and load-balancer exposure

One commenter argued that AWS users behind certain managed services are less exposed because those services terminate TCP connections and AWS is applying updates to its infrastructure.

"AWS Web Application Firewall, Application Load Balancer, Classic Load Balancer, TLS Listeners on Network Load Balancer, Cloud Front, API Gateway. Customers using the above services do not receive TCP connections from untrusted sources directly when following best practices. AWS is applying updates to the underlying infrastructure of these services and no immediate customer action is required if you are using these services. We still recommend customers update their self-managed instances behind these services within the next 30 days."

— Shank, quoting an AWS security bulletin

That does not remove the need to patch self-managed instances. It changes the urgency for hosts that are not directly reachable from untrusted networks.

Timeline

All times are CDT (UTC−5).

When	What
October 1, 5:12 PM	Eric Dumazet posts the fix, crediting Xinyang Ge of Anthropic as reporter
October 5	The fix is merged into the kernel networking tree
October 11	Linux 7.2.10 and 6.18.56 ship the fix; 7.3-rc7 follows that night
October 15, 4:56 to 7:16 AM	Linux 6.12.113, 6.6.159, 6.1.190, 5.15.223, and 5.10.272 ship the fix; the CVE record is published at 7:08 AM
October 16	Oracle publishes UEK errata with the fix for Oracle Linux 7 through 10
October 18	Linux 7.3 is released with the fix
October 24	Amazon Linux 2023's kernel6.18 package is fixed
October 27	Anthropic's Frontier Red Team describes a remote root exploit for the bug, built by Claude in its lab
October 29	Ubuntu still lists its kernels as vulnerable; Amazon Linux 2023's kernel6.12 package is fixed; GitHub repositories referencing the CVE appear, one created at 7:22 PM describing a race trigger

What the Hacker News discussion added

The discussion was sharply divided between practical patch planning, criticism of the disclosure, and debate about how serious the bug is in real deployments.

Several commenters criticized the source article and the broader disclosure for alarming language without enough mitigation detail.

"There is zero context, zero information, very alarming language but nothing about mitigation factors. This is a terrible way of communicating vulnerabilities."

— louwrentius

Others were skeptical of Anthropic's unpublished exploit claim.

"Bro, we've gained a root RCE with this vulnerability. No, you can't see a PoC, just trust me bro, we have a root RCE, also buy our IPO pls bro."

— kristjank

A counterpoint was that the bugs are mostly pre-existing and that finding them is a net security improvement.

"2027 is going to be the year of two to three major CVEs per day. The discourse on this is weird, sounds at times as if these are 'because of AI.' These are mostly pre-existing bugs, some very old, and they've been lurking. If they all get found we exit the other side more secure and reliable."

— api

Ubuntu users noted that a fixed kernel was available in the -proposed repository before it reached -stable.

"If you're on Ubuntu you can upgrade by pulling the -43 version from the -proposed repo. Crazy they still haven't shipped it to -stable."

— iknowstuff

One commenter objected to the Hacker News title dropping the word "Linux," which matters because the bug does not affect BSD, macOS, or Windows.

"This is a Linux vulnerability. If you're running *BSD or Mac or Windows, not affected."

— asveikau

Another commenter criticized NVD's affected-version formatting as unusable for determining which kernels are in scope.

"In an earlier report, it said only affected is kernel 4.4, not all since. This quite dramatic now. I see. NVD affected versions format is the culprit. Entirely unusable. We do have versions, branch names and tags for a reason."

— rurban

Bottom line

CVE-2026-98432 is a critical-scored Linux kernel use-after-free in IPv4 TCP handshake handling that is reachable before application authentication. Upstream stable kernels fixed it in October 2026, but distribution kernels lagged: Ubuntu and RHEL had no shipped fix as of October 29, 2026, while Debian, SUSE, Oracle Linux UEK, and some Amazon Linux 2023 kernels were fixed. The safest immediate actions are to identify the running kernel on every host and node, reboot into a fixed kernel as soon as the distribution ships one, and treat IPv4-option filtering as an interim control rather than a complete mitigation.