Vulnerabilities

Red Hat ships fix for 9.8 Linux TCP flaw; Ubuntu LTS still waits

Red Hat has patched critical Linux TCP flaw CVE-2026-98432, but Ubuntu LTS fixes remain in testing. What UK admins should do now.

Server racks illustration with the headline Linux TCP flaw: RHEL fixed, Ubuntu waits

Red Hat has released fixed kernels for CVE-2026-98432, a critical remote flaw in Linux’s IPv4 TCP code, and now rates it 9.8. Ubuntu’s long-term support releases are still waiting: Canonical’s fixes sit in an opt-in testing channel with no release date.

What happened

On 1 November Red Hat shipped patched kernels for Red Hat Enterprise Linux 8, 9 and 10 to close CVE-2026-98432, a use-after-free bug in how the Linux kernel sets up incoming IPv4 TCP connections. The errata are RHSA-2026:93414 (RHEL 8.10), RHSA-2026:93412 (RHEL 9.8) and RHSA-2026:93413 (RHEL 10.2), and each needs a reboot before it protects anything. Red Hat initially gave it a lower score (Moderate at 5.9, according to The Hacker News) and now rates it Critical at 9.8, matching the Linux kernel’s own CVE team.

Canonical has not yet fixed it in the normal update channel. On 2 November it said kernels for Ubuntu 22.04, 24.04 and 26.04 LTS were in its -proposed pocket, a testing channel that systems only use if they are told to. Canonical says the kernels are still going through testing across its 2,000-plus certified hardware platforms and has given no date for general release. When I checked Ubuntu’s CVE tracker this morning (last updated 3 November), all supported releases were still listed as vulnerable, the three newest LTS releases as “work in progress”. The older 20.04, 18.04 and 16.04 releases are still without a fix, and on those versions it will come through Ubuntu Pro’s Expanded Security Maintenance.

SUSE, Debian and Oracle Linux all had fixes out during October, and Amazon Linux between 24 and 30 October. According to CloudLinux, AlmaLinux 9 and 10 still only had fixed kernels in testing on 2 November.

The technical picture

The bug is a race condition in the kernel’s TCP handshake handling. When a server accepts an IPv4 connection, it hands the IP options from the pending request to the new socket without making a copy. If a retransmitted connection request is being processed on another CPU at that moment, that CPU can still be reading the options when the memory is freed. The result is a read of memory that has already been handed back. The main IPv6 path is not affected.

The flaw is serious because of where it sits. No login is needed and no application bug is involved: the CVE record says a remote peer can trigger it with connection requests bearing the IPv4 Record Route or Timestamp options, aimed at any TCP port that is listening. The fault has been in the kernel since version 4.4, so most Linux servers in service today run an affected kernel unless patched.

Scores differ mainly on attack complexity: SUSE and Amazon Linux rate it 8.1, Amazon listing a crash with possible memory corruption as the likely outcome, while the kernel CVE team argues the attacker controls both sides of the race.

Anthropic says it has demonstrated the worst case. On 27 October Anthropic said an unreleased internal research model had written a remote root exploit for servers running a Multipath TCP (MPTCP) listener. According to Anthropic, the proof of concept took about 53 minutes from first leaking a kernel address to running a root command. The code has not been released, and CloudLinux says it could not reproduce the result and notes MPTCP is off by default on Enterprise Linux. No vendor or CERT has reported attacks, and the CVE was not in CISA’s Known Exploited Vulnerabilities catalogue when the catalogue was last updated on 30 October.

Timeline of CVE-2026-98432 from CVE publication on 15 October to Ubuntu fixes still in testing on 3 November

Why it matters for UK organisations

RHEL and Ubuntu are the workhorses of UK hosting, public cloud and internal data centres. A fleet of 22.04 or 24.04 servers fully patched through the normal channel is still exposed today, and many patch dashboards will show those machines as green.

That also matters for compliance. Cyber Essentials requires high and critical updates to be applied within 14 days of release. Strictly, Ubuntu’s clock has not started, because nothing has gone to the updates pocket. But the scheme is a floor, not a defence, and the risk is already public. Regulated operators should record their interim decisions.

The MPTCP detail also needs care. Go has enabled MPTCP on listening sockets by default since version 1.24, so many container platforms, proxies and internal tools may have MPTCP listeners their owners never chose. Canonical stresses the bug is in the IPv4 TCP path, not MPTCP, so disabling MPTCP narrows one route without closing the hole.

Expert view

When we test Linux estates, the kernel is usually the most out-of-date component on the box. Packages update nightly, but the running kernel only changes when somebody schedules a reboot, and those reboots tend to slip. I would expect a long tail of RHEL servers to have the fixed package installed but still be running the old kernel weeks from now.

Red Hat’s interim mitigation is reasonable, as long as you treat it as a stopgap. It is an nftables rule that discards incoming IPv4 TCP packets with IP options set. Red Hat itself says the rule will not stop every exploitation attempt and could disrupt workloads that depend on IPv4 options. A kernel engineer also pointed out on the oss-security list that the filter works per host, so container-to-container traffic on one host can slip past it.

Red Hat’s upgrade to 9.8 is a lesson in itself. In my experience, teams that rank work purely by vendor CVSS would have parked this in a routine cycle in mid-October. Exposure matters more than the number: a race you can trigger without credentials against any listening port deserves urgent attention whatever score is attached.

What to do now

  1. RHEL, AlmaLinux 8, Debian, Oracle Linux, SUSE and Amazon Linux: install the fixed kernel and reboot, or apply a vendor live patch where one exists. Confirm the running kernel on each host (Cyber Essentials: security update management).
  2. Ubuntu 22.04, 24.04 and 26.04 LTS: decide this week whether internet-facing hosts should take the -proposed kernel now. Otherwise, be ready to roll out the moment the fix reaches the updates pocket.
  3. Ubuntu 20.04 and older: make sure Ubuntu Pro or ESM is enabled so the fix arrives when it is published.
  4. Until patched: on exposed hosts, consider Red Hat’s packet filter that discards IPv4 TCP packets with IP options set, after testing it against your workloads. Restrict which TCP ports are reachable from the internet (Cyber Essentials: firewalls).
  5. Inventory MPTCP listeners, including Go services, and switch MPTCP off where it is not needed. Treat this as reducing exposure, not as a fix (Cyber Essentials: secure configuration).
  6. Watch for exploitation news: follow the NCSC, CISA’s KEV catalogue and your distribution’s tracker, and be ready to bring dates forward if attacks are reported.

Bottom line

CVE-2026-98432 has been public for three weeks, Anthropic says it has built a working remote root exploit, and some of the most widely deployed server operating systems in the UK still have no generally released fix. RHEL users should patch and reboot now. Ubuntu users should decide whether to take the testing kernel or rely on filtering and tighter exposure for a few more days, and record that decision.

Sources

Related Posts