CVE-2026-98432: a 9.8 kernel TCP use-after-free Ubuntu has not patched yet

The Linux kernel rates it 9.8, Red Hat rates it 5.9, and Ubuntu still lists every maintained release as work in progress. How to tell whether you are exposed.

By the Maborak engineering team · 2026-10-29 · 6 min read

CVE-2026-98432 is a use-after-free in the Linux kernel’s IPv4 TCP code. The kernel’s own CVE team rates it 9.8 Critical; Red Hat’s public CVE page rates it 5.9 Moderate; the machine-readable Red Hat advisory, Oracle and SUSE rate it 8.1; Amazon rates it 7.0. As of 29 October 2026, Ubuntu has not released a fixed kernel — its CVE page lists every maintained release as “work in progress”.

Checked 29 October 2026. The description, scores and Ubuntu statuses are from the primary entries linked under Sources. The exploitation detail is a vendor report, not a reproduction of ours. The probe at the end was run in a Linux container on this machine.

A correction to the obvious headline: the CVE record was published on 15 October, the 9.8 score was added on 24 October, and Ubuntu still has no fix. “Patch Ubuntu now” is not yet an available action; the correct action is to measure exposure and wait for the Ubuntu Security Notice.

Background

The flaw is in how the kernel handles the IP options attached to an incoming IPv4 TCP connection. It was introduced by a 2016 change that moved request-socket processing out of the listener lock (tcp/dccp: install syn_recv requests into ehash table, upstream 4.4). The kernel fix was written on 5 October and backported to the maintained stable branches — 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3 — before the CVE was published ten days later. For a distribution’s user, that upstream fix matters only once the vendor rebuilds its kernel package.

Mechanics

Two ownership paths for the same options object race against each other.

When a connection completes, tcp_v4_syn_recv_sock() transfers ownership of the pending request’s ireq_opt to the child socket (newinet->inet_opt) without copying it.
A second CPU can still be processing a retransmitted SYN for the same request socket. tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt under rcu_read_lock() only, and ip_build_and_send_pkt()/ip_options_build() read opt->optlen twice.
If the child socket is freed while that read is in flight, the reader is using freed memory. TCP child sockets have no SOCK_RCU_FREE, and inet_sock_destruct() releases inet_opt with a plain kfree().

A close variant exists for request-socket migration (net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program): inet_reqsk_clone() makes the old request socket and its clone share the same ireq_opt, and tcp_v4_reqsk_destructor() also frees it with kfree().

The fix is small: use kfree_rcu() in both destructors, matching the options-replacement paths that already used it, so the object survives any in-flight RCU reader. IPv6 is not affected by the first path because tcp_v6_syn_recv_sock() copies the options; the tcp_v6_reqsk_destructor() migration case is the subject of a separate patch.

Impact

The disagreement between scores is the story to read before the headline. The kernel team assumes an attacker who sends a TCP request carrying IPv4 Record Route or Timestamp options and resends it to win the race, and rates attack complexity low because both sides of the race are attacker-induced. Red Hat rates complexity high — it says the race is hard to win, the likely result is a kernel crash, and “no confidentiality or integrity impact has been demonstrated”. Oracle and SUSE use the same vector as Red Hat’s advisory file, which rates confidentiality and integrity impact high. Ubuntu takes the kernel team’s number and marks the issue High priority.

Anthropic reported on 27 October that its model wrote a working exploit: a two-stage attack that first leaks a kernel address to defeat KASLR, then overwrites a callback pointer to run a command as root. [reported] In Anthropic’s test, leaking the address took 48 minutes and reaching command execution took five more. The report ties the root path to servers running a multipath TCP listener; neither the CVE record nor the kernel fix mentions MPTCP, and the post does not say whether a server without an MPTCP listener can be taken over the same way.

As of 29 October, no advisory reports in-the-wild exploitation, and the issue is not in a recent copy of CISA’s Known Exploited Vulnerabilities catalog. Exposure requires a reachable IPv4 TCP listener; a host that runs no such service is not remotely reachable by this bug.

Probe

There is no safe public exploit to run and none is needed. Triage is: what kernel is running, is MPTCP enabled, and what TCP services are listening. This runs on any Linux host or container and uses only /proc:

#!/bin/sh
echo "kernel:      $(uname -r)"
. /etc/os-release 2>/dev/null; echo "release:     ${PRETTY_NAME:-unknown}"
printf "mptcp sysctl: "; cat /proc/sys/net/mptcp/enabled 2>/dev/null || echo absent
printf "mptcp proto:  "; grep -ci mptcp /proc/net/protocols 2>/dev/null || echo 0
printf "ipv4 tcp:     "; grep -c . /proc/net/tcp 2>/dev/null
printf "ipv6 tcp:     "; grep -c . /proc/net/tcp6 2>/dev/null

Run in a container on this machine: [reproduced]

kernel:      6.8.0-117-generic
release:     Alpine Linux v3.24
mptcp sysctl: 1
mptcp proto:  2
ipv4 tcp:     1
ipv6 tcp:     1

Two things come out of that. MPTCP is enabled by default on this kernel (net.mptcp.enabled is 1), which is the feature the reported root exploit used. And the probe tells you the kernel version to compare against the vendor advisory — not a verdict by itself. For a precise Ubuntu answer, check the CVE page or, with Ubuntu Pro, ask it directly:

pro fix CVE-2026-98432

Mitigation

For Ubuntu, there is no fixed kernel to install as of 29 October. The order of work is therefore: reduce exposure, then monitor, then patch.

Know what is listening. A remote attacker needs a reachable IPv4 TCP service. Firewall and review exposed listeners first; that bounds the risk regardless of the score.
MPTCP is on by default. The reported root exploit needs an MPTCP listener. If nothing on the host uses MPTCP, sysctl -w net.mptcp.enabled=0 (and persist it) removes that path; verify no application relies on it. Neither Ubuntu nor Red Hat sanctions this as a mitigation, so treat it as defence in depth, not a fix.
Watch for the USN. Ubuntu publishes a Security Notice when the kernel lands; pro fix CVE-2026-98432 and the CVE page both show the fixed package once it exists. Red Hat has deferred its fix to a future update.
Other distributions already have fixes. Debian (6.12.113-1, and 6.1.190-1 for bookworm), Oracle Linux (ELSA-2026-500397/8/9), SUSE (kernel-default 6.12.0-160000.40.1 or later) and Amazon Linux (kernel6.18, and kernel6.12 from 29 October) have shipped packages. If you build your own kernel, move to a fixed upstream version.

Verification

uname -r on each host, compared with the fixed version in the vendor advisory. A version string proves the package, not that the running kernel is the patched one; reboot after the kernel update.
pro fix CVE-2026-98432 on Ubuntu Pro, or apt-get changelog linux-image-$(uname -r), to confirm the fix is present in the installed package.
cat /proc/sys/net/mptcp/enabled to confirm whether MPTCP is still enabled after a change.

No vendor recommends cherry-picking the single fix; the kernel community’s position is to update to a current stable kernel.

Sources

Ubuntu: CVE-2026-98432 (published 15 October, updated 28 October 2026; 9.8 Critical, priority High, work in progress).
Linux kernel CVE-2026-98432 record and the fix commit.
Red Hat CVE-2026-98432 (5.9 / advisory 8.1).
Anthropic: discovering vulnerabilities with Claude (27 October 2026).
The Hacker News summary and MPTCP documentation.

Topics: security, linux, infrastructure

Back to all articles