TCP Use-After-Free: CVE-2026-98432 / CVSS 9.8

Atlas2026-10-29T11:00:00-05:00作者 Atlas Security大模型,Anthropic,Meta,扩散模型,招聘HR,网络安全原文 ↗

#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 5:15 PM CDT, October 31, Ubuntu's tracker still reads "Vulnerable" for its kernel on every release, and Red Hat, which now rates the bug Critical too, 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. Go programs open those listeners by default, per the Go Security Team. See the timeline.

#Key facts

Field	Detail
CVE	CVE-2026-98432, "ipv4: free inet_opt and ireq_opt after an RCU grace period," issued by the Linux kernel CNA
Severity	Critical, CVSS 3.1 9.8 ( AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H ), the kernel CNA's score. Red Hat also rates it Critical, CVSS 3.1 9.8, raised from Important (8.1) on October 30. SUSE rates it important, Ubuntu rates it High, and Oracle and Amazon rate it Important with CVSS 3.1 8.1.
Weakness	Use-after-free of IPv4 option data during the TCP handshake (the record lists no CWE)
Impact	Per the CNA's scoring notes: kernel heap contents disclosed to the remote peer, kernel memory corruption, or a crash. Red Hat's bulletin: a remote, unauthenticated attacker "could exploit a race condition during TCP connection request processing to trigger remote code execution."
Fixed in	7.2.10 and 6.18.56 (Oct 11) · 6.12.113, 6.6.159, 6.1.190, 5.15.223, and 5.10.272 (Oct 15) · 7.3 (Oct 18)
No fix yet	Ubuntu (every release) and Red Hat Enterprise Linux (RHEL) 8, 9, and 10, as of 5:15 PM CDT, October 31. AlmaLinux's fixed kernels are still in testing. Upstream branches that reached end-of-life before 5.10 get no fix.
Proof of concept	Anthropic says Claude built a remote root exploit for servers with a multipath TCP listener. It hasn't published the exploit.
CVE records	Published on cve.org on October 15. NVD lists it as "Received," with no analysis of its own, as of 5:15 PM CDT, October 31.
Credit	Reported by Xinyang Ge of Anthropic. Fixed by Eric Dumazet and reviewed by Kuniyuki Iwashima, per the fix commit.

#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."

Release line	Status on Oct 31, 2026	Fixed in	Released
7.3	Mainline	7.3 (from 7.3-rc7)	Oct 18, 2026
7.2	Stable	7.2.10	Oct 11, 2026
6.18	Longterm	6.18.56	Oct 11, 2026
6.12	Longterm	6.12.113	Oct 15, 2026
6.6	Longterm	6.6.159	Oct 15, 2026
6.1	Longterm	6.1.190	Oct 15, 2026
5.15	Longterm	5.15.223	Oct 15, 2026
5.10	Longterm	5.10.272	Oct 15, 2026
4.4 – 5.4	End-of-life upstream	distro fixes only	—

#Distribution status

Distribution kernels carry backported fixes under their own version numbers, so check the tracker, not the upstream number. As of 5:15 PM CDT, October 31:

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: rated Critical, CVSS 3.1 9.8, since October 30. RHEL 8, 9, and 10 and OpenShift Container Platform 4 and 5 are listed as affected, with no fix; RHEL 6 and 7 aren't affected (CVE page). Its bulletin, RHSB-2026-016, says "Red Hat is expediting the release of fixes," gives an nftables mitigation (compared below), and says any product that relies on the RHEL kernel, including RHEL CoreOS, "is also potentially impacted."
AlmaLinux: fixed kernels for AlmaLinux 8, 9, and 10 (
```
kernel-4.18.0-553.180.2.el8_10
```
,
```
kernel-5.14.0-687.61.2.el9_8
```
, and
```
kernel-6.12.0-211.69.2.el10_2
```
) have been in its testing repository since October 30, ahead of RHEL. AlmaLinux will move them to production after community testing, and its errata don't list them yet (announcement).
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. openSUSE Leap 16.0 is fixed, and Leap 15.6 is listed as affected (CVE page).
Oracle Linux: rated Important, CVSS 3.1 8.1. Unbreakable Enterprise Kernel (UEK) errata for Oracle Linux 7, 8, 9, and 10 came out October 16: ELSA-2026-500397, ELSA-2026-500398, and ELSA-2026-500399 (CVE page). The page lists only the UEK kernels.
Amazon Linux: rated Important, CVSS 3.1 8.1, and every kernel is fixed. On Amazon Linux 2023, the default
```
kernel
```
(ALAS2023-2026-3365, October 30),
```
kernel6.12
```
(ALAS2023-2026-3335, October 29), and
```
kernel6.18
```
(ALAS2023-2026-3251, October 24). On Amazon Linux 2, the core
```
kernel
```
(ALAS2-2026-4065) and the 5.4, 5.10, and 5.15 Extras kernels (ALAS2KERNEL-5.4-2026-135, ALAS2KERNEL-5.10-2026-137, and ALAS2KERNEL-5.15-2026-120), all October 30 (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, and Go programs do by default: the Go Security Team says "as of Go 1.24, Go programs enable MPTCP by default for listen sockets on Linux." The default follows the
```
go
```
line in the program's
```
go.mod
```
, and applies only where the kernel allows MPTCP (
```
net.mptcp.enabled = 1
```
, as on the Debian 12 kernel we checked; AlmaLinux says it ships MPTCP off). The Go team adds that "the underlying bug is not specific to MPTCP. It is possible that systems with no MPTCP listeners are vulnerable to similar attacks." The check is below.

Red Hat now rates it as the CNA does. It raised the bug from Important (8.1) to Critical (9.8) on October 30, citing "the lack of network prerequisites and the potential for severe system instability." Its bulletin says "Systems accepting inbound TCP connections are most directly exposed."

#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. On October 31 it also listed a Go HTTP server whose

go.mod

says

go 1.24

, and skipped the same server built with

go 1.23

#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, SUSE Linux Enterprise Server 16.0 and the 15 LTSS releases, openSUSE Leap 16.0, Oracle Linux's UEK kernels, and Amazon Linux 2 and 2023, the fix is out. AlmaLinux's is in its testing repository. On Ubuntu and RHEL, it isn't out yet, as of 5:15 PM CDT, October 31. 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's bulletin and AlmaLinux now publish nftables rules that drop incoming IPv4 TCP packets carrying IP options. Red Hat says its rule "reduces exposure to this vulnerability but cannot fully prevent it." The following is Atlas's interim recommendation, the same rule as AlmaLinux's, 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.

If you manage the firewall with iptables, this rule does the same job from the

raw

table, which also runs before connection tracking:

1iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROP

The

u32

match reads the IPv4 hea