CVE-2026-98432: Ubuntu's fix sits in -updates, not -security

CVE-2026-98432 is fixed for most Ubuntu LTS kernels, just not where your patch tooling looks. As of 9 November 2026, the fixed linux, linux-aws and linux-gcp kernels for 22.04, 24.04 and 26.04 have sat in the -updates pocket since 5-6 November, according to Launchpad's publishing records. Ubuntu's CVE tracker still says "pending", and no Ubuntu Security Notice exists.

That gap matters because Ubuntu's default unattended-upgrades setup installs only from -security. By the end of this post you will know which kernel versions close the hole, why Azure is the exception, where the official firewall workaround leaks on container hosts, and when rebuilding node images beats waiting for the notice.

CVE-2026-98432 key facts, as of 9 November 2026

• The bug: a use-after-free in ip_options_build() when a SYN carrying IPv4 options races a retransmitted SYN, present since Linux 4.4, per NVD.
• The fix: upstream commit e3f33b0a1d89 by Eric Dumazet, a four-line change that switches two frees to kfree_rcu(), reported by Xinyang Ge of Anthropic.
• Stable kernels carrying it: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10, per the CVE record.
• Ubuntu priority: critical, tracker last updated 7 November.

Is CVE-2026-98432 patched in Ubuntu? In -updates, not in -security

Ubuntu built the fixed kernels from late October. Canonical's 2 November blog post said they were in -proposed while it ran tests on more than 2,000 certified servers and devices. The same version strings the tracker lists as "pending" have since been published to -updates for every cloud flavour except Azure:

Kernel package	22.04 (jammy)	24.04 (noble)	26.04 (resolute)
linux (generic)	5.15.0-203.213	6.8.0-149.149	7.0.0-43.43
linux-aws	5.15.0-1120.127	6.8.0-1069.74	7.0.0-1017.18
linux-gcp	5.15.0-1121.131	6.8.0-1073.81	7.0.0-1017.19
linux-azure (-proposed only)	5.15.0-1126.135	6.8.0-1073.82	7.0.0-1020.21

The Ubuntu Server documentation shows the -updates origin commented out in the default 50unattended-upgrades file. A fleet that relies on automatic security updates will not pick these kernels up until Canonical copies them to -security. Installing them also needs a reboot, which Canonical's post states plainly. Run uname -r afterwards and compare against the table.

Who scored it 9.8, and who scored it lower

The 9.8 did not come from NVD. NVD lists the record as "Awaiting Analysis", and the CVSS 3.1 vector on its page carries source ID 416baaa9-dc9f-4396-8d5f-8c081fb06d67, which the CVE record identifies as the Linux kernel CNA. Vendors split from there:

Scorer	Score	Vector detail
Linux kernel CNA	9.8 Critical	CVSS 3.1, AC:L
Red Hat	9.8 Critical	CVSS 3.1, AC:L
Ubuntu	9.8 / 9.2 Critical	CVSS 4.0 adds AT:P (attack requirements present)
Amazon Linux	8.1 Important	CVSS 3.1, AC:H

Amazon's advisory describes the result as primarily a crash or potential memory corruption. Red Hat's statement concedes that reliable code execution "requires precise heap control", yet keeps Critical because no network prerequisites apply. If you triage by score alone, our piece on why a CVSS 9.8 can wait explains when a high score overstates the risk. The exploit evidence below is why this one does not.

Is CVE-2026-98432 remotely exploitable?

Yes. The CNA's scoring notes say an unauthenticated peer triggers it by sending IPv4 Record Route or Timestamp options in a SYN, before any application authentication. The race sounds hard to win, and that is the strongest argument for waiting. Anthropic's write-up answers it: a lost race only fails the handshake, so an attacker can retry indefinitely. Its proof of concept leaked a kernel pointer in 48 minutes and ran a root command five minutes later.

That exploit targeted a server with a Multipath TCP (MPTCP) listener, and Canonical's post said no other exploit was known when it was written. The bug itself is in plain IPv4 TCP, which Canonical, the Go security team and a CIQ kernel engineer all stress. One detail matters for Kubernetes fleets: Go programs enable MPTCP by default on Linux listen sockets as of Go 1.24, per that Go announcement.

Two narrower facts from the upstream description: IPv6 is not affected by the main issue, and the second variant needs net.ipv4.tcp_migrate_req=1 or a migrating BPF program. AlmaLinux notes that setting is off by default.

How to mitigate CVE-2026-98432 before you can reboot

Install the fixed kernel first. Everything below only reduces risk until you can:

1. Drop inbound IPv4 TCP with IP options. Ubuntu's tracker publishes an nftables rule matching ip hdrlength > 5 and says it "reduces the risk but does not fully prevent exploitation". It breaks TCP connections that depend on IPv4 options.
2. Hook prerouting on container hosts. Ubuntu's rule uses the input hook. PhotoStructure's test found an input-hook rule missed traffic forwarded to a Docker-published port; a prerouting hook caught it. Traffic between containers on the same host can bypass either. Nobody we found has tested Kubernetes CNI setups, so check your own drop counters.
3. Disable MPTCP if you do not use it. Check sysctl net.mptcp.enabled and list listeners with ss -lnMp. This removes Anthropic's demonstrated path only.
4. Skip init_on_free=1. It was proposed on oss-security; the CIQ analysis concluded it "isn't a mitigation for this CVE".

Neither Canonical's CVE page nor its blog post mentions a Livepatch for this CVE, so do not plan around one.

When moving node images beats waiting for Ubuntu

Other distributions shipped through their normal security channels days earlier. Amazon Linux 2023 fixed its kernel6.18 package on 24 October and its default kernel on 30 October. The Bottlerocket advisories are dated 26 and 30 October, Red Hat shipped RHEL 8, 9 and 10 on 1 November, and the Debian tracker shows bookworm and trixie fixed in their security suites.

For Ubuntu nodes on AWS or GCP, switching distributions mid-incident is the wrong move: the fixed kernel exists today. Rebuild your node image with -updates enabled for the kernel and roll the node group. We have not checked whether Canonical's published EKS images already carry these kernels, so verify uname -r on a fresh node rather than trusting the image date. Azure nodes are the harder call: the fix is only in -proposed, so filter at prerouting now and decide whether you accept a pre-release kernel.

The longer question is cadence. From CVE publication on 15 October, Bottlerocket shipped in 11 days and Ubuntu reached -updates in 21, with -security still to come. If your Kubernetes implementation treats the node OS as an afterthought, that gap is the cost.

Make kernel CVEs an image-pipeline job, not a ticket

Closing a kernel CVE like this quickly takes three things: which kernel flavour each node runs, how to rebuild and roll an image from a named pocket, and how to prove the new kernel booted. If you cannot answer those for your fleet today, our DevOps and cloud engineering team can audit your Ubuntu nodes against the versions above, wire kernel CVEs into your image pipeline, and add infrastructure monitoring that flags kernel drift before the next 9.8 lands.