Ubuntu’s Kernel Security Gap: The Cost of Waiting for a Fix

CVE-2026-98432 is a use-after-free in the Linux kernel’s IPv4 TCP connection path. The upstream kernel team rates it 9.8 Critical under CVSS 3.1. Anthropic has described a proof of concept that reaches remote command execution as root.

The fix has been merged upstream and backported to maintained stable branches. The remaining question for Ubuntu users is when that fix reaches the update channel their machines actually use.

In a November 2 post, Canonical said fixes for Ubuntu 22.04, 24.04 and 26.04 were available in the opt-in -proposed pocket, while the generic Ubuntu 26.10 kernel was fixed in the main archive. Older releases were still pending. But Canonical’s live CVE tracker, updated November 3, labels the same generic 26.10 build “vulnerable, work in progress.” For LTS releases, it also lists the proposed build numbers as work in progress.

That leaves a real operational gap—and a status-reporting mismatch worth checking before you act.

What the bug does

During an IPv4 TCP handshake, Linux first creates a lightweight request socket, then a full child socket. In one path, the kernel transfers the request socket’s IP-options object to the child without copying it. Another CPU can still be reading that object while it builds a response to a retransmitted SYN.

The readers use RCU, which allows them to finish using an object while other work proceeds. But when the child socket is destroyed, the affected code freed the object immediately with kfree(). That could leave a concurrent reader with a pointer to freed memory. The upstream fix changes the deallocation to kfree_rcu(), which waits for existing RCU readers to finish.

A related race exists during request-socket migration when net.ipv4.tcp_migrate_req=1 or a BPF SO_REUSEPORT migration program is used. The upstream announcement describes both paths and notes that IPv6 does not have the first issue because it duplicates the options. It identifies a separate, CALIPSO-only IPv6 migration issue; check that issue’s own advisory for its status. Linux kernel CVE announcement

The demonstrated network path uses specially constructed IPv4 TCP packets carrying IP options and carefully timed connection requests. This is a kernel bug; the application does not have to process application-level data. The vulnerability is not specific to Multipath TCP (MPTCP).

What the exploit shows—and what it doesn’t

Anthropic’s October 27 report describes an exploit against a Linux server with an MPTCP listener. It first leaks a kernel pointer to defeat KASLR, then uses the same bug to hijack control flow and run a shell command as root. In the demonstration, the pointer leak took 48 minutes and command execution took another five.

A failed race only makes the handshake fail; it does not crash the whole machine. That lets an attacker retry. Anthropic’s post describes the exploit stages but does not provide a ready-to-run proof of concept. Anthropic’s research

MPTCP was part of that demonstration, not a stated requirement of the underlying vulnerability. Red Hat says affected OpenShift nodes remain vulnerable with MPTCP disabled. Turning MPTCP off may reduce exposure to the published technique, but it does not fix the kernel bug.

As of its November 2 bulletin, AWS said it had no evidence that the vulnerability had been exploited in the wild. CISA’s October 29 KEV announcement named two other vulnerabilities, not this one. Those are limited observations, not proof that targeted exploitation is impossible. AWS bulletin · CISA announcement

Severity scores also depend on the scoring model. The kernel CVE record and Ubuntu list CVSS 3.1 at 9.8 Critical. Ubuntu also lists CVSS 4.0 at 8.3 High; that model records attack requirements as present. Oracle lists CVSS 3.1 at 8.1, with high attack complexity. The scores differ, but each vendor’s guidance is to install the fixed kernel.

The release timeline

The upstream stable fixes listed in the kernel announcement are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. Distribution kernels often backport fixes without adopting those upstream version numbers, so compare against your distribution’s package status rather than uname -r alone.

What Canonical’s status means

Canonical says its kernel fixes are tested across more than 2,000 certified servers and devices before they move into the normal updates pocket. Its September kernel strategy describes a two-week release cycle: a preparation week, followed by certification and regression testing. During that period, release candidates can appear in -proposed for users who run their own acceptance tests. Canonical did not give a release date for these updates. Canonical’s November 2 status post · Kernel release strategy

The November 2 post covers the generic linux package. Its reported status was:

There is a discrepancy to resolve before treating this table as current: the CVE tracker, updated November 3, marks the 26.10 build above as “vulnerable, work in progress,” even though the November 2 post calls it fixed in the main archive. The tracker gives the same work-in-progress label to the 22.04, 24.04 and 26.04 builds that the post says are in -proposed. The latter can mean that the package is still being qualified for the normal updates pocket; the 26.10 entry is harder to reconcile. Check the live tracker and the package in your configured archive before relying on either label. Ubuntu’s live CVE tracker

The tracker also lists kernel flavours separately: AWS, Azure, GCP, KVM, HWE, NVIDIA, Raspberry Pi, OEM, real-time and others. Their release status can differ from the generic kernel. A cloud instance running an -aws or -azure kernel should be checked against that exact package, not the generic table.

The delay is understandable as an engineering trade-off: a kernel that fails to boot on certified hardware can create its own outage. But operators need to know how long a fix will remain in qualification and which package is affected. “A fix exists” and “the fixed kernel is in my normal update channel” are different states.

What to do while your kernel is pending

• Identify the running and installed kernels. Run uname -r and dpkg -l 'linux-image*' | grep ^ii. A kernel can be installed without being active until the next reboot.

• Check the exact flavour. Use Ubuntu’s tracker and the package names on the machine. Do not infer the status of an AWS, Azure, GCP, HWE or other flavour from the generic linux package.

• Ask Ubuntu Pro about your machine. pro fix --dry-run CVE-2026-98432 simulates the Pro client’s assessment without installing anything. It can report whether installed packages are affected and whether a fix is available. Ubuntu Pro client documentation

• Decide whether to use -proposed. Canonical documents it for users who can run their own kernel acceptance tests and need the candidate before it reaches the normal updates pocket. Treat it as pre-release software; test it against your hardware and workload first.

• Reduce network exposure. Restrict inbound access to required ports and sources. Filtering IPv4 TCP packets that carry IP options can reduce exposure, but it is not a complete fix and may disrupt unusual networking. AWS and Red Hat publish examples and limitations.

• Treat MPTCP changes as defense in depth. Disabling MPTCP narrows the conditions used by Anthropic’s demonstration; it does not remove the vulnerable code.

• Plan the reboot. The fix takes effect only after the machine boots the fixed kernel. After reboot, run uname -r again.

Once the fixed package is available in your normal update channel, the standard update is:

sudo apt update
sudo apt upgrade
sudo reboot

For Ubuntu 22.04, 24.04 and 26.04, Canonical’s documented -proposed procedure is:

sudo add-apt-repository --component main --pocket proposed http://archive.ubuntu.com/ubuntu
sudo apt update
dpkg-query -W -f '${source:Package}\t${binary:Package}\n' | awk '$1 ~ "^linux-meta" { print $2 }' | xargs sudo apt install -t $(. /etc/os-release && echo $VERSION_CODENAME)-proposed --only-upgrade
sudo reboot

That command assumes the kernel is managed through an Ubuntu kernel meta-package, as in Canonical’s example. Confirm the package selected for your release and flavour before using it. After rebooting, verify the running kernel and recheck the CVE status.

Should you leave Ubuntu over this?

A distribution change during an active incident is not a patch. First update or isolate the systems that are exposed. Later, use this incident to measure your vendor’s response: time from disclosure to a fixed package, time from package to the normal channel, coverage across the kernel flavours you run, and the reboot required to activate the fix.

For this incident, the public record shows an upstream fix, a candidate available to some Ubuntu LTS users, and a mismatch between Canonical’s blog and live tracker for 26.10. That is enough to justify scrutiny and a fleet plan. It is not, by itself, a reason to migrate in a hurry.

Status checked November 3, 2026. Kernel package availability changes quickly; confirm the current vendor tracker and the exact kernel flavour before acting.