CVE-2026-98432: the Linux TCP bug with a two-line fix

Update, 3 November: Red Hat has shipped fixed kernels. Ubuntu's fixes are still in testing. Details are at the end.

The fix for CVE-2026-98432 changes two lines in the Linux kernel. Two calls to kfree() became kfree_rcu(). The bug has been in the kernel since Linux 4.4, released in January 2016, and the kernel CVE team scored it 9.8 because anyone who can reach a TCP port can trigger it, with no login.

Anthropic says an unreleased Claude model wrote a remote root exploit for it, against servers with a multipath TCP (MPTCP) listener. I wanted to know what the two lines change and which servers an attacker can reach with it.

Two CPUs, one set of options

A TCP SYN can carry IPv4 options such as Record Route or Timestamp. The kernel keeps them in ireq_opt so it can answer with them in the SYN-ACK. Then:

1. The handshake completes, and tcp_v4_syn_recv_sock() hands the options to the new socket as inet_opt. It doesn't copy them.
2. A retransmitted SYN for the same request lands on another CPU. That CPU starts building a SYN-ACK from the same options while holding only rcu_read_lock().
3. The connection closes, and inet_sock_destruct() frees the options at once with kfree().
4. The second CPU is still reading them in ip_options_build().

That's a use-after-free. The CVE record lists three outcomes: kernel heap memory sent back in the SYN-ACK, out-of-bounds writes in the kernel, and a crash through skb_under_panic().

A second route goes through request socket migration. It needs net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program, and the sysctl is off by default. IPv6 connections avoid the main race because tcp_v6_syn_recv_sock() copies the options.

The two lines

Eric Dumazet wrote the fix, commit e3f33b0a1d89, after Xinyang Ge of Anthropic reported the bug:

--- a/net/ipv4/af_inet.c+++ b/net/ipv4/af_inet.c@@ void inet_sock_destruct(struct sock *sk)-	kfree(rcu_dereference_protected(inet->inet_opt, 1));+	kfree_rcu(rcu_dereference_protected(inet->inet_opt, 1), rcu);--- a/net/ipv4/tcp_ipv4.c+++ b/net/ipv4/tcp_ipv4.c@@ static void tcp_v4_reqsk_destructor(struct request_sock *req)-	kfree(rcu_dereference_protected(inet_rsk(req)->ireq_opt, 1));+	kfree_rcu(rcu_dereference_protected(inet_rsk(req)->ireq_opt, 1), rcu);

kfree_rcu() waits for an RCU grace period before it frees the memory, so a CPU that has already started reading can finish first. The readers used RCU all along, and the other code that replaces these options already called kfree_rcu(). These two destructors were the exceptions.

Upstream, the fix is in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. Distros backport fixes under their own version numbers, so go by your distro's advisory and not by this list.

Which servers are exposed

An attacker needs three things to reach the bug: an unpatched kernel from 4.4 on, an IPv4 TCP port they can connect to, and a path for SYN packets with IP options to get to the host. The race runs between two CPUs, so I'd expect a single-CPU machine to be safe from it. I haven't seen anyone confirm that.

You don't need any special software. The bug sits in the handshake, before your web server, SSH or database sees the connection, as AlmaLinux points out.

The known root exploit also needs an MPTCP listener, and you may have those without knowing it. Programs built with Go 1.24 or later open MPTCP listeners by default on Linux when the kernel allows it, according to the Go security team. Mattias Geniar checked his own Ubuntu machine and found 712 of them, all from Go programs he had never set up for MPTCP. The upstream default for net.mptcp.enabled is 1. AlmaLinux ships with it set to 0.

How hard it is to exploit

Hard. The attacker has to win a race between CPUs, and Red Hat says reliable code execution needs precise control of the kernel heap. Oracle, SUSE and Amazon rate the attack complexity high and score the bug 8.1. Anthropic hasn't published its exploit. As of 2 November, no vendor or CERT had reported attacks in the wild, and CISA hadn't added the CVE to its KEV catalogue (Rescana's summary collects these ratings).

I still wouldn't wait. A lost race fails only that one handshake, so an attacker can retry for as long as they like. In Anthropic's test, leaking a kernel pointer took 48 minutes and getting command execution took five more. A script doesn't mind waiting that long. The kernel team rates the complexity low for that reason, since the attacker drives both sides of the race, and Red Hat now uses the same 9.8 score.

Two more points kept me from relaxing. Nobody knows yet whether root is possible without MPTCP, and a crash or a heap leak doesn't need root at all. Atlas counted at least six public repositories that claim a race trigger or a proof of concept. I haven't looked at them.

What I'd do on a server

Install your distro's fixed kernel and reboot into it. Until you can, compare uname -r with your distro's advisory and check MPTCP and the migration setting:

sysctl net.mptcp.enabledsudo ss -lnMpsysctl net.ipv4.tcp_migrate_req

Red Hat suggests dropping inbound IPv4 TCP packets that carry IP options. The rule lowers the risk without closing the hole, so try it on one machine first:

table inet cve_2026_98432 {    chain input {        type filter hook input priority -310; policy accept;        ip protocol tcp ip hdrlength > 5 counter drop    }}

Skip the filter if your network uses CIPSO security labels, because those travel as IP options.

If you don't need MPTCP, turn it off and restart the services that listen. The setting applies to new sockets only, and each network namespace keeps its own value:

echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/99-no-mptcp.confsudo sysctl --system

That removes the setup the known exploit uses. The bug stays until you boot a fixed kernel.

Update, 3 November

Red Hat has shipped fixed kernels for its main RHEL streams. Canonical has built Ubuntu's fixes and is still testing them.

Red Hat

Red Hat put out its first errata on 1 November, a day before I wrote this post, and now rates the bug Critical at 9.8.

The fix takes effect after you reboot into the new kernel. On 2 November Red Hat still listed OpenShift 4 and RHEL 9 real-time as affected, so check the advisory for the product you run.

Ubuntu

Canonical posted its status on 2 November. The LTS fixes are in the -proposed pocket for people who run their own kernel acceptance tests. Canonical is testing them on more than 2,000 certified servers and devices and hasn't given a release date.

Canonical's post lists 26.10 as fixed, but the Ubuntu CVE tracker, updated on 3 November, still shows 22.04 to 26.10 as vulnerable with work in progress. Cloud and HWE kernels have their own rows on the tracker, so look up the kernel you boot.

If you test your own kernels and want the fix now, Canonical gives these steps for kernels installed through a meta-package:

sudo add-apt-repository --component main --pocket proposed \  http://archive.ubuntu.com/ubuntusudo apt updatedpkg-query -W -f '${source:Package}\t${binary:Package}\n' \  | awk '$1 ~ "^linux-meta" { print $2 }' \  | xargs sudo apt install -t $(. /etc/os-release && echo $VERSION_CODENAME)-proposed --only-upgradesudo reboot

These packages haven't finished qualification, so put them on a test machine before production.

Scanning

Cyber Security News reports that Marcus Hutchins saw residential proxies and Russia-based VPN servers probing port 443 with MPTCP connections from 2 November, and that he suspects a link to this CVE. The same report counts about 2.1 million servers that accept MPTCP on that port. Neither the outlet nor I could open his original post, so treat the numbers with care. They count servers with MPTCP, and say nothing about how many run an unpatched kernel. The report also says nobody has published a remote code execution exploit yet, while several denial-of-service proofs of concept are public.

References

1. CVE Program. CVE-2026-98432 record. The bug description, the 9.8 score, and affected and fixed versions.
2. Linux kernel. Commit e3f33b0a1d89, on a GitHub mirror, and the same commit on git.kernel.org.
3. Rescana. Linux Kernel CVE-2026-98432: Critical TCP Use-After-Free, RHEL Fixed, Ubuntu Pending. Vendor scores, exploitation status and a summary of Anthropic's research post.
4. Lilting Channel. CVE-2026-98432 Linux TCP Use-After-Free Can Give Unauthenticated Root on MPTCP Listeners. A walkthrough of the race and the exploit stages.
5. Mattias Geniar. CVE-2026-98432: which Linux kernels are still vulnerable. Distro status as of 3 November, and his MPTCP listener test.
6. AlmaLinux. CVE-2026-98432: Patched kernels available in testing. Impact, the MPTCP default, the migration setting and the limits of the filter.
7. Red Hat. RHSB-2026-016. Affected products and the nftables rule.
8. Go Security Team on oss-security. Protecting against CVE-2026-98432. Go's MPTCP default and why turning it off is only a partial fix.
9. Atlas. Linux's October 2026 TCP Use-After-Free. A timeline and a count of public proof-of-concept repositories.
10. Canonical. Fixes available in -proposed pocket for CVE-2026-98432, 2 November 2026.
11. Ubuntu. CVE-2026-98432 tracker, updated 3 November 2026.
12. Cyber Security News. Attackers Started Scanning in the Wild for Linux Kernel RCE Flaw, Ubuntu Releases Fixes, 3 November 2026.