Linux kernel TCP use-after-free CVE-2026-98432 enables remote root

CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP connection-setup path. The Linux kernel CVE team scored it 9.8. The practical worst case — unauthenticated remote root — is real but narrower than the headline, and as of October 30 two of the biggest server distros had not shipped a fixed kernel.

What the bug is

The flaw is a race in how the kernel handles incoming TCP connection requests. tcp_v4_syn_recv_sock() transfers ownership of the request socket's ireq->ireq_opt (the IPv4 options buffer) to the child socket without copying it; a concurrent retransmitted SYN can free that buffer while it is still in use. The same pattern can be hit during request-socket migration when net.ipv4.tcp_migrate_req is enabled or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program is in play. Affected kernels go back to 4.4. The CVE record describes a plain IPv4 TCP fix — it does not mention Multipath TCP.

Where the "remote root" claim comes from

The attention-grabbing part is not in the CVE record. In a Frontier Red Team writeup on October 27, Anthropic said an unreleased internal model built a working exploit that reached root on a server running an MPTCP listener, leaking a kernel pointer to defeat KASLR and getting from first packet to a root shell in about 53 minutes. We covered that research when it dropped, and the caveat stands: the MPTCP-listener requirement comes solely from Anthropic's account. BleepingComputer reports that remote code execution has not been publicly demonstrated against servers without an MPTCP listener, and no in-the-wild exploitation is confirmed. The flaw is not in CISA's KEV catalog.

One exposure wrinkle worth noting: Go 1.24+ enables MPTCP by default on Linux TCP listeners when the kernel supports it, so services may be listening on MPTCP without their operators having chosen to.

A severity the vendors don't agree on

The 9.8 is the kernel CVE team's number. Red Hat scored it far lower and frames the practical impact as denial-of-service, citing the high attack complexity of actually winning the race. That gap — critical-RCE versus hard-to-win DoS — is the real decision a security team has to make, and it hinges on whether you have MPTCP listeners exposed.

Action checklist

1. Patch where a fix exists. Debian has shipped fixed kernels — 6.1.190-1 on Bookworm, 6.12.113-1 on Trixie (Debian tracker). Oracle Linux shipped on October 16. Ubuntu (22.04/24.04/26.04/26.10) and Red Hat (RHEL 8/9/10) were still listing fixes as in-progress or planned on October 30 — check your distro's advisory directly, because that status is moving.
2. Find your MPTCP exposure. Enumerate listeners that negotiate MPTCP, including anything built with Go 1.24+. Disabling MPTCP alone is not a fix — the bug is in core TCP — but it removes the only path to RCE demonstrated so far.
3. Apply the stopgap if you can't patch. CIQ recommends dropping inbound IPv4 TCP packets that carry IP options (e.g., via nftables) until a kernel is available. Test it: legitimate traffic rarely uses IP options, but confirm before deploying.
4. Prioritize internet-facing hosts. A race-condition UAF reachable pre-auth over the network belongs at the top of the queue for anything exposed.

Context

This is the second kernel memory-safety flaw we've written up this cycle, after the GhostLock rtmutex UAF — both are use-after-frees turned into privilege wins, and both show how much of the exploitability debate now turns on narrow preconditions rather than the base CVSS. Here the preconditions (an MPTCP listener, winning a network race) are doing the heavy lifting, which is exactly why the kernel team's 9.8 and Red Hat's lower score can both be defensible. Patch on the facts of your own fleet, not the headline number.