On 5 October the Linux kernel took a patch about as small as kernel patches get: two calls to kfree() became kfree_rcu(), in two places in the IPv4 TCP code. Ten days later the kernel CVE team assigned CVE-2026-98432; on 24 October it added a 9.8 score. Debian had a fixed kernel by 16 October. Ubuntu and Red Hat still have none, and no date.

That is the finding of the week, and it is louder than the headline that made the bug famous.

What is broken

The flaw sits in the code that accepts IPv4 TCP connections — code that runs on any server with an open port. The trigger is a TCP SYN carrying IPv4 options, specifically Record Route or Timestamp. Ordinary traffic almost never sends these, but nothing stops a client from doing so. The kernel stores them with the pending connection request in ireq_opt. When the handshake completes, tcp_v4_syn_recv_sock() hands the options to the new child socket without copying, so the request socket and the child point at the same memory. If the client retransmits its SYN at the right moment, another CPU can pick that up and build a SYNACK from the same options in ip_options_build(). If the child socket is torn down in the meantime, inet_sock_destruct() frees the options with a plain kfree() — and the SYNACK path reads memory that is already gone.

The bug dates to Linux 4.4 (January 2016), when request sockets began to be processed without holding the listener lock. Anything from that version on, unpatched, on a host that accepts IPv4 TCP connections is exposed; the main path needs no special configuration. Only a second, narrower path through request-socket migration requires net.ipv4.tcp_migrate_req=1 or a BPF program attached, both off by default. IPv6 dodges the main path because there the options are copied.

The claim

On 27 October Anthropic's Frontier Red Team published a post saying an unreleased internal research model had written a working exploit that executes commands as root, remotely and without credentials, against servers with a Multipath TCP listener. Two stages: winning the race makes the kernel read an attacker-controlled length field and copy extra bytes into the SYNACK it sends back, and once a reply carries a kernel pointer, KASLR is defeated. Then the same bug overflows a buffer and overwrites a callback pointer with the address of a payload already staged in kernel memory; when the kernel calls it, a command of the attacker's choosing runs as root. Anthropic says the address leak took 48 minutes in its test and command execution another five.

The post does not publish the exploit code, the kernel version or the configuration tested, and does not say whether servers without an MPTCP listener can be taken over the same way. TuxCare has not reproduced it, and as of the end of October there was no independent public reproduction. The claim is not out of line with the kernel team's own scoring notes, which describe stale options leaking adjacent kernel heap memory to the peer and steering out-of-bounds kernel writes. This is not a zero-day — the fix preceded the CVE — but it is not theory either.

Why MPTCP suddenly matters

MPTCP lets one connection use several network paths at once. Applications get it only by asking when they open a socket, so for years most teams could assume they were not running it. Go changed that: since Go 1.24, Go programs on Linux enable MPTCP on listening sockets by default where the kernel supports it. A Go-based API gateway, reverse proxy or internal service built with Go 1.24 or later may therefore be holding an MPTCP listener nobody ordered. The Go Security Team's mitigation is GODEBUG=multipathtcp=0 at runtime, or a godebug multipathtcp=0 line in go.mod at build time — and it calls that fragile, because a single listener left exposed still leaves the host vulnerable. More importantly, the bug is not MPTCP-specific, and the team says systems with no MPTCP listeners may be exposed to similar attacks.

Enterprise Linux is partly shielded: RHEL 8, 9 and 10 ship with MPTCP disabled, so a Go service there quietly falls back to a plain TCP listener unless someone set net.mptcp.enabled=1.

The argument about the score

The kernel team rates it 9.8 — network attack vector, no privileges, low complexity — on the grounds that both sides of the race are attacker-induced, since the attacker controls the SYN, the retransmission and the teardown. Ubuntu shows the same 9.8. Red Hat started at Moderate (5.9) and moved to Important (8.1) on 29 October; Oracle, SUSE and Amazon also score 8.1. The entire gap is one metric: attack complexity, high rather than low. That is a fair technical point about a race, and less persuasive when losing the race costs the attacker one connection attempt. If your patch SLA keys off vendor severity, this CVE was probably filed as "moderate" for most of October.

What to do

Check first: uname -r, sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req, and ss -H -lMn — every line that command prints is an MPTCP listener. Where nothing needs MPTCP, sysctl -w net.mptcp.enabled=0, persist it under /etc/sysctl.d/, and restart services that already opened listeners. A second layer for hosts with no fixed kernel is a firewall rule that drops inbound TCP packets carrying IPv4 options: nft add rule ip cve_2026_98432 prerouting meta l4proto tcp ip hdrlength != 5 drop. It has not been tested against an exploit, but it blocks the documented trigger; try it in staging for collateral damage. Then install fixed kernels as they ship, by reboot or rebootless patch.

The uncomfortable part is the schedule. Coordinated disclosure worked here — fix first, CVE next, exploit code withheld. But a two-line upstream fix still has to become a vendor kernel build, then a shipped package, then a reboot or live patch on every exposed host. While Ubuntu and Red Hat give no dates, that gap, not the CVSS number, decides how long enterprise systems stay exposed.

Sources