CVE-2026-98432: a 9.8-rated Linux kernel TCP bug, a root exploit, and no Ubuntu or Red Hat kernel yet

TechScripts Nepal · Kathmandu · October 30, 2026 · 7 min read

A race condition in the Linux kernel's IPv4 TCP code, tracked as CVE-2026-98432, can let one CPU free memory while another is still reading it. The Linux kernel CVE team rates it 9.8 out of 10. On October 27, Anthropic's Frontier Red Team published research showing the bug could be chained into running commands as root on a server, without credentials, when that server has a Multipath TCP (MPTCP) listener.

As of October 30, several distributions have shipped fixes, while Ubuntu and Red Hat Enterprise Linux had not published fixed kernels in the sources we checked. Here's what is established, what is disputed, and what to do.

A note on sourcing: the exploit research comes from Anthropic, which is also the company behind the AI model that helped us research this post. We've attributed every exploit claim to Anthropic and relied on distribution trackers for patch status. We read the Ubuntu and Debian trackers and the Red Hat bug and portal pages directly. For the exploit itself we relied on Anthropic's post and secondary write-ups.

What the bug is

According to the Ubuntu, Debian and Red Hat descriptions, when a TCP connection is being set up, the kernel hands the IP options from the incoming connection request to the new child socket without copying them. If a retransmitted SYN arrives at the same moment, the kernel can build its reply from options that another CPU is freeing. The options are released with a plain kfree(), not a deferred free, so the reply code can read freed memory in ip_options_build(). A similar race exists when connection requests are migrated between sockets, which happens with the net.ipv4.tcp_migrate_req setting or a BPF reuseport migration program.

The upstream fix changes the frees to kfree_rcu() in two places, so the memory is released only after a grace period. IPv6 is not affected by the first issue; a related IPv6 migration case is to be handled in a separate patch.

One aggregator lists Linux 4.4 and later as affected, with stable fixes in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10, and 7.3 unaffected. Treat that as a guide, since distribution kernels backport fixes and version numbers alone can mislead.

The exploit claim

Anthropic's post describes a proof of concept against a Linux server listening with MPTCP. It needs no credentials or user interaction. In outline, the exploit first wins the race so the kernel over-reads and leaks a kernel pointer, which defeats address randomization, then overwrites a kernel callback pointer to run a shell command as root. Anthropic reports about 48 minutes for the leak and about five more to reach command execution in its test. It says a lost race fails the handshake without crashing, so an attacker can retry. These timings come from one proof of concept.

Anthropic's post doesn't say whether this has been exploited in the wild, and the secondary reports we read say it hasn't been observed.

What is disputed or unknown

• Does it need MPTCP? The CVE record and the fix don't mention MPTCP. The demonstrated root exploit needs an MPTCP listener, and one write-up says no path to root without one is known yet. That doesn't mean the bug is harmless elsewhere: the underlying flaw sits in ordinary IPv4 TCP handling, and a crash (denial of service) or memory corruption is still possible. Red Hat's own description says the main result is a crash or possible memory corruption.
• How severe is it? The kernel team scores it 9.8, with low attack complexity. Red Hat first rated it lower, then on October 29 moved to 8.1 (Important), still describing the score as preliminary and setting attack complexity to high. Oracle, SUSE and Amazon reportedly sit in a similar range. The disagreement is mostly about how common MPTCP listeners are in production, which we can't settle for you.
• Is Go involved? One write-up says Go 1.24 and later enable MPTCP on listeners by default, so Go services may be exposed without anyone having chosen it. We haven't confirmed that against the Go release notes, so check it for your own services.
• Dates. Sources differ on when the fix landed upstream. Debian's tracker puts it in 7.3-rc7; another report says October 5. The CVE record was published October 15.

Patch status as of October 30

• Fixed: Debian 12 (6.1.190-1) and Debian 13 (6.12.113-1) per Debian's tracker. Oracle, SUSE and Amazon Linux have also been reported as fixed.
• Not yet fixed: Ubuntu lists 22.04, 24.04, 26.04 and 26.10 as vulnerable with a fix "in progress" for each, and 16.04, 18.04 and 20.04 as vulnerable. Red Hat lists RHEL 8, 9 and 10 as affected with no fixed packages, and RHEL 7 as not affected.

Check your vendor's tracker today, because this is changing daily.

What to do now

1. Find your exposure. List internet-facing Linux hosts, and for each, the kernel and whether anything is listening with MPTCP. On recent versions of iproute2, ss -M lists MPTCP sockets.
2. Patch where a fixed kernel exists, and reboot. Live-patching may help where your vendor offers it for this CVE; confirm before relying on it.
3. Reduce the demonstrated path while you wait. Setting net.mptcp.enabled to 0 stops MPTCP sockets being created, and for Go programs GODEBUG=multipathtcp=0 turns it off per program. Both only remove the precondition from Anthropic's exploit. They don't fix the bug, and Red Hat says it has no mitigation that meets its criteria.
4. Limit who can reach the service. Restricting exposure of TCP services on unpatched hosts is a sensible precaution, not a fix. No vendor has confirmed that filtering packets with IPv4 Record Route or Timestamp options reduces risk, so don't count on it.
5. Watch for the vendor kernel, then schedule the reboot. Kernel fixes need one, which is the part teams put off.

Why this one is awkward

It combines the things that make kernel bugs hard to handle: a high headline score, vendor ratings that disagree, a working exploit described in public, and the two most common enterprise distributions still without a fixed kernel days later. The right response depends on facts about your own estate that no advisory can give you: which hosts are internet-facing, which services use MPTCP, and how fast you can reboot them.

Why teams get help with this

When an advisory like this lands, the slow part isn't reading it. It's discovering what you run, because the answer usually lives in several heads and spreadsheets: kernels vary by host, some services are containerized, and nobody is sure which language runtimes turn on MPTCP. Then comes the part that gets postponed, scheduling reboots on systems people are afraid to restart.

At TechScripts Nepal we help teams build that inventory and a patch-and-reboot routine they can repeat, so the next kernel advisory becomes a lookup instead of a scramble. When there isn't capacity in-house, one of our engineers can work inside your team for the length of the effort (how that works). If you'd like a second pair of eyes on your exposure, tell us about your environment. For a related case of an exploited flaw in a platform with scripting, see the ServiceNow sandbox escape.