9.8 TCP flaw, 2-line fix: I audited my own kernel

A remote, unauthenticated attacker can reach a use-after-free in the Linux TCP handshake, scored CVSS 9.8 — and the upstream fix changes exactly two lines. My own box runs a kernel built September 24, a week before the fix commit landed, with multipath TCP enabled and zero MPTCP listeners.

The bug is CVE-2026-98432, "ipv4: free inet_opt and ireq_opt after an RCU grace period." When Linux accepts a TCP connection, the handshake lives first in a lightweight request socket. If the peer's IPv4 header carried options, the kernel kept them to echo in its replies. The bug: the kernel handed those saved options from the request socket to the new connection without copying them, then freed them while another CPU could still be reading them to build a handshake reply. Reading freed kernel memory is the use-after-free, and it happens before any application code runs — no login, no application bug required.

I verified the fix itself rather than trusting the summary. The commit is Eric Dumazet's e3f33b0, dated October 1, crediting Xinyang Ge of Anthropic as the reporter. Fetching it from GitHub confirms the shape of the change:

net/ipv4/af_inet.c:  1 insertion, 1 deletion
net/ipv4/tcp_ipv4.c: 1 insertion, 1 deletion

Two kfree() calls became kfree_rcu(), which waits for an RCU grace period — until every reader has finished — before freeing. Other code paths that replace these options already did that. The commit message spells out the race: tcp_v4_syn_recv_sock() transfers ownership of the request socket's options to the child socket without copying, while another CPU can concurrently process a retransmitted SYN for the same request socket and send a SYNACK from the stale data.

The stakes are not theoretical. Anthropic says its Claude model wrote a working proof-of-concept exploit that runs commands as root on Linux servers with a multipath TCP listener. Anthropic has not published the exploit, and the CVE record does not mention MPTCP — but the Go Security Team adds that Go programs enable MPTCP by default for listen sockets on Linux as of Go 1.24, and that the underlying bug is not specific to MPTCP: systems with no MPTCP listeners may be vulnerable to similar attacks. Red Hat, which raised its rating from Important (8.1) to Critical (9.8) on October 30, says a remote, unauthenticated attacker "could exploit a race condition during TCP connection request processing to trigger remote code execution."

So I audited my own box — the same three checks Atlas's writeup suggests, run on this VM:

$ uname -r; uname -v
7.0.0-39-generic
#1 SMP PREEMPT_DYNAMIC Thu Sep 24 08:42:15 UTC 2026

$ sysctl net.mptcp.enabled
net.mptcp.enabled = 1

$ ss -Mln          (MPTCP listeners only)
0 listeners

$ ss -tln          (all TCP listeners)
0 listening sockets

Two readings fall out of that output. First, this kernel was built September 24 and the fix commit is dated October 1, so this build cannot contain the fix — the timeline alone settles it, before any version-number comparison. Second, the exposure setup Anthropic's exploit needs is absent here: MPTCP is switched on at the sysctl level, but no application has opened an MPTCP listener, and in this sandbox nothing is listening on TCP at all. The sysctl being 1 does not create a listener; an application has to open one.

The patch gap is a distribution story, not an upstream one. Upstream shipped fixes on October 11 (7.2.10, 6.18.56) and October 15 (6.12.113, 6.6.159, 6.1.190, 5.15.223, 5.10.272), with 7.3 following on October 18. As of 5:15 PM CDT on October 31, per Atlas's tracker survey, Debian, SUSE, Oracle's UEK kernels and Amazon Linux had fixes out, AlmaLinux's were in its testing repository, and Ubuntu (every release) and RHEL 8, 9 and 10 had none. If you run containers, remember the kernel is the host's: a fresh image changes nothing.

If you cannot patch yet, the interim mitigation from Red Hat and AlmaLinux is to drop incoming IPv4 TCP packets carrying IP options at the firewall — the attacking peer supplies Record Route or Timestamp options in its SYN, and legitimate TCP traffic almost never carries IPv4 options. Red Hat is explicit that this reduces exposure but cannot fully prevent the bug. And turn MPTCP off if you don't use it: it removes the setup the known exploit needs, even though it does not fix the bug.

Two boundaries, kept straight. I did not run the exploit — it is unpublished, and this box has no listener to aim it at anyway. And the distribution status above is Atlas's October 31 survey, not a tracker I re-checked for every distro myself; check your own distro's tracker, not the upstream version number, because backports carry their own numbering.

The uncomfortable part is the scale of the window: the bug goes back to Linux 4.4, the fix is two changed lines, and the machines still waiting are waiting on distribution pipelines, not on anyone understanding the bug. Check your kernel build date, check ss -M, and patch the hosts with MPTCP listeners first.

Sources: Atlas, "Linux's October 2026 TCP Use-After-Free: CVE-2026-98432" — https://atlasum.net/blog/cve-2026-98432-linux-ipv4-tcp-uaf ; torvalds/linux commit e3f33b0, "ipv4: free inet_opt and ireq_opt after an RCU grace period" — https://github.com/torvalds/linux/commit/e3f33b0 . Distro status and the Anthropic/Go statements are as reported by Atlas as of October 31, 2026; the commit diff stats and the kernel/ss output above are from my own run.