Three weeks after a critical Linux kernel flaw was disclosed, Ubuntu's long-term support releases still have no fix in their regular update channel — while Red Hat and Debian have already shipped theirs. The gap has turned a patching delay into a public argument about patching speed.

The flaw, tracked as CVE-2026-98432, is a use-after-free bug in the kernel's IPv4 TCP connection setup code. When a server accepts a new connection, the kernel passes IP options from the incoming request to the new socket without copying them. If a client retransmits its connection request while another processor is still reading those options, the kernel can read memory it has already freed — a race an unauthenticated remote attacker can trigger by sending connection requests carrying IPv4 Record Route or Timestamp options to any listening TCP port. No login is needed, and the bug has been present since kernel 4.4. The kernel's CVE team rates it 9.8 out of 10.

The flaw drew attention on October 27, when Anthropic said an unreleased Claude research model turned the bug into a working remote root exploit in about 53 minutes, defeating kernel address space layout randomization and running commands as root on a server with a Multipath TCP listener. Anthropic has not released the exploit, and no exploitation in the wild has been confirmed.

Red Hat ships, Ubuntu tests

Red Hat shipped fixed kernels for Red Hat Enterprise Linux 8, 9 and 10 on November 1, under advisories RHSA-2026:93414, RHSA-2026:93412 and RHSA-2026:93413, and raised its own severity rating from 5.9 to 9.8, now calling the flaw critical. Debian shipped fixes for its Bookworm and Trixie releases. A reboot is needed after installing the update.

Ubuntu is the outlier. Canonical said on November 2 that fixed kernels for 22.04 LTS, 24.04 LTS and 26.04 LTS are sitting in its -proposed pocket — an opt-in testing channel that machines do not pull from unless administrators deliberately enable it. No date has been given for moving the fixes to the regular updates pocket. Ubuntu 26.10, the non-LTS release, already has the fix in its regular stream, while 20.04 and older releases have no fix yet outside Expanded Security Maintenance.

Canonical says the delay is testing: it tests kernel updates across more than 2,000 certified servers and devices, and will move the fixes once those tests finish. That did not stop a Hacker News thread on the delay from reaching the front page on November 2.

What administrators can do now

Red Hat published a stopgap on October 30: an nftables rule that drops inbound IPv4 TCP packets carrying IP options, blocking the trigger for the race. Canonical has cautioned that disabling Multipath TCP alone is not enough, because the flaw is not specific to MPTCP — the vulnerable code path is in general TCP connection setup.

Administrators who cannot wait can enable -proposed and install the test kernels — 5.15.0-203.213 for 22.04, 6.8.0-149.149 for 24.04 and 7.0.0-43.43 for 26.04 — though those packages are still in testing. The upstream fix landed in early October and is included in stable kernels from 5.10.272 through 7.3.

A test of patching speed

The episode is less about one bug than about what "long-term support" means when a critical flaw is public and an AI-built exploit exists, even unreleased. Every major distribution had the same upstream fix; the difference is how quickly each got it to ordinary servers. Red Hat and Debian measured that in days. Ubuntu's LTS users are still waiting.