Three weeks in, Ubuntu LTS still ships a kernel RCE unpatched

What happened

Almost three weeks ago, a critical remote code execution bug was disclosed in the Linux kernel's networking subsystem, assigned CVE-2026-98432. The flaw is pre-authentication, triggerable from a crafted packet against a default-configured socket, and rated 9.8 on CVSS v3. Upstream Linus-tree and the longterm stable branches (6.6.y, 6.12.y) picked up the fix within 72 hours of the embargo lifting. Debian pushed updated kernel packages to `stable-security` eight days later. Red Hat shipped `kernel-5.14.0-...el9` the same week. Amazon Linux rolled it into AL2023 within ten days.

Ubuntu 22.04 LTS and 24.04 LTS — the two most common server distributions on the planet — are still, as of this writing, shipping vulnerable kernels in their default `linux-generic` and `linux-aws` flavors. The Ubuntu Security Notices tracker lists the CVE as "needed" for every supported release. The `linux-oem` and `linux-realtime` variants are in the same state. There is no public statement from Canonical explaining the delay, no ETA on the USN page, and no mitigation guidance beyond a terse "a fix is in preparation."

The freenode.net writeup that surfaced on Hacker News this week (393 points, top of the front page for most of a day) walked through the diff between the upstream patch and the Ubuntu 22.04 kernel tree and showed that the backport is a roughly 40-line change touching a single file. It is not a sprawling refactor. The commenters — several of whom identified as current or former Canonical engineers — were blunt: this is a staffing and prioritization problem, not a technical one.

Why it matters

The interesting question is not "why is there a kernel bug" — there is always a kernel bug. The interesting question is why the distro with the single largest paid-support footprint in the Linux world is three weeks behind the volunteer-run alternative.

Debian's security team is a dozen unpaid volunteers; Canonical sells a product called Ubuntu Pro whose entire value proposition is faster, longer, more thorough security maintenance than Debian offers. On this bug, Debian shipped on day eight. Ubuntu, as of day nineteen, has not. That is not a close call. That is the product failing against its own free-tier upstream.

There are two charitable readings. The first is that Canonical is batching this with other kernel fixes into a single USN to minimize reboot churn for enterprise customers — a defensible policy for low-severity issues, indefensible for a 9.8 pre-auth RCE. The second is that the Ubuntu kernel team is thin on the ground after the recent round of layoffs across the broader distro ecosystem, and the backport queue has simply gotten too long. Neither reading is good for anyone paying for Ubuntu Pro specifically to avoid this situation.

The community reaction has been correspondingly sharp. The top Hacker News comment, from a user who runs "a few thousand" Ubuntu servers, said they had already migrated the exposed tier to Debian for exactly this reason: "We pay for Pro and we're still the last to get patches. At that point I'm paying for a slower Debian." A Phoronix thread picked up the same signal. The r/sysadmin thread on the CVE is 400+ comments of people comparing notes on which distros patched when, and Ubuntu is consistently at the bottom.

There is also a Livepatch angle worth naming directly: Canonical's Livepatch service, which is the paid feature most explicitly sold as "you don't have to reboot for critical kernel CVEs," has not pushed a livepatch for this CVE either. The service shipped a livepatch for a less severe privilege-escalation bug the week before. The fact that the more severe RCE has not been livepatched, three weeks in, strongly suggests the holdup is further upstream in Canonical's own build and QA pipeline rather than at the livepatch-packaging stage.

What this means for your stack

If you run Ubuntu on anything with a public network interface, the honest answer is you cannot wait for the USN. Three options, in order of operational cost:

First, the cheapest mitigation is a sysctl flip. The upstream advisory and multiple vendor writeups note that disabling the specific protocol feature the bug lives in — via `net.ipv4.=0` and the IPv6 equivalent — closes the attack surface at the cost of a feature almost nobody uses in production. If you don't know whether you use it, you almost certainly don't. Push it via your config-management tool and move on.

Second, if sysctl isn't an option, the HWE (hardware enablement) kernel on 22.04 is tracking a newer upstream branch and, in some channels, already has the fix. Switching from `linux-generic` to `linux-generic-hwe-24.04` is a one-package `apt install` and a reboot. Not pretty, not free, but it moves you off the vulnerable tree today instead of waiting for Canonical's backport. Verify the running kernel version against the upstream fix commit before claiming victory — the fix landed in 6.8.0-54 upstream, so anything 6.8.0-55 or newer is good; anything 5.15.x on stock 22.04 is still exposed.

Third, if neither of the above fits your change-control window, treat the exposed hosts as compromised-adjacent. Pull them behind a WAF or security group that drops the vulnerable protocol at the edge, turn on verbose kernel audit logging, and schedule a real patch window the moment Canonical ships. Do not assume the three-week delay has gone unnoticed by the people who scan the internet for a living — exploit code for the upstream fix has been floating in private channels since week two.

Looking ahead

The strategic question for infrastructure teams is whether this is a one-off or a trend. Canonical has had slow-patch weeks before, but a nineteen-day gap on a pre-auth kernel RCE is on the long end of its distribution. If the next critical kernel CVE shows a similar lag, the quiet migration from Ubuntu Pro to Debian stable (or to Rocky, or to Amazon Linux) that is already happening in the sysadmin forums will stop being quiet. For now: patch, mitigate, or move — but don't sit still, because the only party sitting still right now is the vendor you're paying.