The Kernel Fix Shipped in Early October. Ubuntu and Red Hat Still Have Nothing to Install.

There is a comfortable version of CVE-2026-98432 where a critical kernel bug got found, patched, and handled before it mattered. The bug did get found, and it did get patched. The handling is going badly, and the reasons are more interesting than the vulnerability.

Start with what the kernel security team actually published. CVE-2026-98432 is a use-after-free in the IPv4 TCP handshake, scored CVSS 9.8 with a network attack vector, low complexity, no privileges required and no user interaction. In plain terms: anyone who can send you a packet can reach it, and they do not need an account.

The mechanics are mundane in the way the good kernel bugs usually are. When a TCP handshake completes, tcp_v4_syn_recv_sock() hands the IPv4 options saved from the client's SYN to the new child socket without copying them. A second CPU can be answering a retransmitted SYN for that same connection at that exact moment, building a SYN-ACK from those same options. If the child socket is torn down first, the options are freed with a plain kfree() while ip_options_build() is still reading them. Eric Dumazet's fix defers the free to an RCU grace period: commit e3f33b0a1d89, merged upstream into 7.3-rc7 and backported across the maintained stable branches — 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10. The CVE was published by the kernel CNA on 15 October.

The bug has been there since Linux 4.4. That is the first thing that should make an infrastructure team sit up, and not because it is subtle. It is because this is code that every Linux TCP listener on the planet has been running for a decade.

Anthropic disclosed on 27 October that one of its Claude research models had turned the flaw into a zero-click remote root exploit against servers running a multipath TCP listener. The company's write-up is specific about the cost. In the first stage the exploit defeats KASLR remotely: the race makes the kernel read an attacker-controlled length field, copy extra bytes back to the attacker, and one of those overreads eventually returns a kernel pointer. In the second stage the same bug overflows a buffer and overwrites a callback pointer with the address of a payload already staged in kernel memory through an ordinary protocol feature, chaining existing kernel functions until an attacker-chosen command runs as root. Leaking the pointer took 48 minutes. Reaching the shell took five more.

Then comes the detail that turns a lab demo into a threat model. A lost race only fails that one handshake. It does not panic the machine. An attacker can keep trying.

Here is where the story stops being about the bug.

Ubuntu's tracker, last updated on 30 October, lists priority High and CVSS 9.8, with the main linux package marked "vulnerable, work in progress" for 22.04 LTS, 24.04 LTS, 26.04 LTS and 26.10. The 20.04, 18.04 and 16.04 releases sit at "vulnerable". There is no fixed kernel to install.

Red Hat's position moved, loudly. Reporting on 29 October, working from Red Hat's own tracker, described RHEL fixes as deferred to a future update and the flaw as Moderate at 5.9 — the argument being that winning the race was hard and the realistic outcome was a crash. The following afternoon Red Hat published advisory RHSB-2026-016 and rated the flaw Critical at 9.8, stating that it is expediting the release of fixes. The bulletin lists RHEL 8, 9 and 10 as directly affected, along with OpenShift Container Platform and anything else that relies on the RHEL kernel, RHEL CoreOS included. As of writing it still offers a mitigation, not a kernel.

Meanwhile the distributions that ship faster have shipped. Debian pushed DSA-6568-1 for trixie (linux 6.12.113-1) and DLA-4841-1 for bookworm (6.1.190-1), with DLA-4850-1 covering the 6.12 backport. Oracle Linux's UEK, several SUSE releases and some Amazon Linux 2023 kernels have fixed packages, according to a tracker summary compiled by ctxsec. AlmaLinux backported the patch itself and published testing kernels on 30 October rather than wait for a fixed RHEL build, writing that a flaw this severe, reachable over the network, was not one it wanted to sit on.

Then there is the part that turned a kernel CVE into a Kubernetes problem.

Go 1.24 enabled multipath TCP by default for listening sockets on Linux. Anthropic's demonstrated exploit needs an MPTCP listener, an enormous amount of network-facing server software is written in Go, and most of the people running it never asked for MPTCP in the first place. The Go security team addressed this on 29 October with an advisory that is careful and slightly alarming in equal measure. The best fix, it says, is a patched kernel. Disabling MPTCP is a per-program setting through GODEBUG=multipathtcp=0, and it is fragile, because one forgotten listener leaves the machine exposed. They also note that while the demonstrated exploit needs MPTCP, the underlying bug is not MPTCP-specific, and systems without an MPTCP listener may still be reachable by other means. At the time, they considered it premature to change Go's default.

Two more facts worth holding onto. A public proof-of-concept exploit was listed by the exploit tracker Sploitus on 30 October, attributed to a GitHub account publishing as Alucard0x1. And CVE-2026-98432 does not appear in CISA's Known Exploited Vulnerabilities catalog in the 30 October edition, with no in-the-wild exploitation reported by any vendor I can find. That is the state of play today. It is not a promise about next week.

The uncomfortable arithmetic is this. The fix was in the stable kernels in early October. Anthropic had working root on 27 October. A public proof of concept existed by the 30th. And the two enterprise Linux distributions with the largest installed bases had no kernel for their customers to install on the 31st. Whatever you think about how hard the race is to win, that is a month-long window in which the only defence available to a great many organisations was a firewall rule.

Red Hat's own mitigation is exactly that: an nftables rule that drops inbound IPv4 TCP packets carrying IP options, matching on a header length greater than five. It works. It is also the kind of rule that goes into a change window, breaks one VPN concentrator nobody remembered was there, and then quietly stays in production for three years.

The second lesson is about how quickly the other side moves now. A research model, not a specialist team with months of target expertise, produced a working remote root exploit against a hardened kernel. The bottleneck in this story was never the exploit. It was the distribution.

If you are working out where to spend the next fortnight of maintenance windows — which hosts actually face the internet, which listeners are speaking MPTCP, and which of your vendors will ship a kernel before somebody picks up that proof of concept — let's talk.