Debian Patched a Critical Kernel Bug in a Day.

A developer took all of their Ubuntu servers offline at the start of November 2026, and wrote a furious post about why. The short version is that a critical Linux kernel bug had a fix available, Debian shipped it in days, and more than 2 weeks later Ubuntu still had not. I think the anger is mostly earned. I also think the full picture is more complicated than the outrage suggests, and both halves are worth your time if you run Linux servers.

What the bug actually is

CVE-2026–98432 is a use after free race condition in the Linux kernel’s IPv4 TCP connection setup. When a TCP connection completes, the kernel hands the pending request’s IP options to the new socket without copying them. If that socket gets torn down while another CPU is still using those options to answer a retransmitted connection request, the kernel ends up reading memory that has already been freed. IPv6 is not affected, because it copies the options instead of sharing them.

The flaw was introduced in Linux 4.4, which shipped in January 2016, so it has been sitting in nearly every Linux server for about a decade. The kernel CVE team rated it CVSS 9.8, near the top of the scale, because the attack comes over the network, needs no privileges, and has low complexity. The upstream fix, written by longtime networking maintainer Eric Dumazet, landed in early October 2026, and the CVE went public on 15 October.

The AI exploit that made everyone pay attention

What took this from a routine high severity bug to a story was Anthropic’s claim, published 27 October, that an unreleased internal research model wrote a working exploit after some initial prompting. The exploit gives an unauthenticated remote attacker root command execution on a server, running in 2 stages, first leaking a kernel address to defeat memory layout randomization, then overwriting a callback pointer to run attacker code. The reporter credited in the kernel fix is an Anthropic researcher, Xinyang Ge, so the same organization found the bug and demonstrated the exploit.

One caveat the loudest posts tend to drop is the precondition. Anthropic’s demonstrated exploit targeted servers with a multipath TCP listener enabled, and the timing it reported was about 48 minutes to leak an address plus roughly 5 more minutes to reach command execution. As of the end of October, no independent researcher had publicly reproduced it, and Anthropic had not released the exploit code, the kernel version, or the test configuration. So this is a real and serious bug, demonstrated by a credible party, with the exact conditions for the public demonstration still narrower than the scariest framing implies.

That precondition is also less exotic than it sounds, which is the part that cuts the other way. The Go Security Team warned on 29 October that Go 1.24 and later turn on MPTCP by default for listen sockets on Linux, so a Go service running inside a Kubernetes pod can open exactly the kind of listener the exploit needs, in the node’s kernel, without anyone choosing to enable it. A lot of modern infrastructure is written in Go. The config that makes this exploitable is closer to a default than to a rare setting someone has to switch on.

How the TCP bug becomes root access, at a high level. The demonstrated chain needed a specific server configuration. Source: Anthropic, kernel CVE record, Oct 2026

Who shipped the fix, and who did not

This is where Ubuntu looks bad. Debian, which is run largely by volunteers, shipped fixes fast. Debian 13 got its patched kernel on 16 October, the day after the CVE went public, and Debian 12 followed on 17 and 22 October. Oracle Linux shipped fixes on 16 October. Amazon Linux 2023 patched its main kernel on 24 October.

Ubuntu did not. By the end of October, every supported Ubuntu release, 22.04, 24.04, 26.04, and 26.10, was listed with a fix in progress but nothing released, and the older 16.04, 18.04, and 20.04 were marked simply vulnerable. For a company that sells security subscriptions and markets Ubuntu with words like timely, enterprise grade, and build with confidence, shipping nothing for a 9.8 rated remote root bug more than 2 weeks after the fix existed upstream is a hard thing to defend. The developer who went public was right to be angry about that specific gap.

Days from the CVE going public to a shipped fix. Others reached the normal updates channel. Ubuntu’s fix reached a testing channel on 3 November. Source: TuxCare, Ubuntu, distribution advisories, Oct and Nov 2026

Ubuntu finally responded, and the response drew its own criticism

On 3 November, 19 days after the CVE went public, Canonical published a blog post explaining where things stood. The fix exists, for Ubuntu 22.04, 24.04, and 26.04, but it is in the proposed pocket, a testing channel that sits before the normal updates channel most people run. Only 26.10, the newest release, had the fix in the standard archive. The older releases, 16.04, 18.04, and 20.04, were still listed as fix pending.

The proposed pocket is not where you want a critical security fix to live. Packages there are not installed by a normal update, so applying the fix means manually enabling a testing repository and running a specific install command before rebooting, rather than the ordinary cycle of updating and restarting. Canonical frames this as its new strategy for accelerating CVE fixes, letting users who run their own kernel acceptance tests opt in early. The company says the delay comes from testing on more than 2,000 certified servers and devices, and that security updates are the only appropriate mitigation it recommends.

That explanation did not land well. The response under the announcement was blunt, and the technical objections in it are fair. A fix for a 9.8 rated remote root bug asking users to pull from a testing channel and run commands by hand is a strange place to end up, and several people pointed out that the proposed builds cover the standard kernels but not the hardware enablement, or HWE, kernels that many 24.04 servers run, so a chunk of users still had no fix path at all. Others noted that Arch Linux had shipped the patch almost 2 weeks earlier through a normal update, and that Canonical offers paid kernel livepatching while asking everyone else to either wait or hand install a test build. The sharpest version of the complaint is simple. The stable kernel team fixed this for free weeks ago, and the distribution that sells security subscriptions is the one telling people to install a test kernel and trust that it works.

Real users started sounding alarms

This stopped being an abstract patch delay when real operators began warning their own users. On 1 November, Anza, which develops the Agave validator client for Solana, told mainnet validators to act on CVE-2026–98432 and labeled the alert urgent. Solana validators need a public IPv4 address, which is the exposed surface, and Anza builds and runs its software on Ubuntu 24.04, one of the releases with no fix. Tim Garcia of the Solana Foundation put the problem in one sentence, that the flaw “is patched in the linux kernel but not yet patched on ubuntu.” AWS, for its part, told customers that turning off MPTCP reduces exposure but does not resolve the issue, and that a kernel update and reboot is the only complete fix.

That is the concrete cost of the delay. A major piece of financial infrastructure, running on Ubuntu because it is the default choice, had to scramble because the distribution had not shipped a fix that had existed upstream for more than 2 weeks.

The caveats that complicate the clean story

The clean version of this is volunteers beat the company. The real version is messier in 2 ways that matter.

First, Ubuntu was not the only commercial distribution that lagged at first. Red Hat, the other big commercial Linux vendor, initially deferred the fix and sat at affected for over 2 weeks, which pointed to a broader problem with how commercial distributions work rather than a Canonical specific failing. Those distributions maintain their own heavily modified kernels and test extensively before shipping, so they move slower than distributions that track upstream closely. That slowness is sometimes the thing enterprise customers are paying for, and sometimes, as here, it leaves them exposed longer. The catch is that Red Hat caught up. It shipped fixed kernels for RHEL 8, 9, and 10 on 1 November, about 17 days after disclosure, and Ubuntu was still the last of the majors to move.

Second, the severity itself is disputed. The kernel team rated the bug 9.8, and that is the number everyone quoted. Red Hat, Oracle, and SUSE independently rated it 8.1, and Amazon rated it 7.0, because they judged the attack complexity to be higher than the kernel team did. The bug is serious on any of those scores, but 9.8 and 8.1 are not the same emergency, and the vendors moving slower were also the vendors who assessed it as somewhat less critical. That does not excuse leaving it unpatched, though it does explain some of the difference in urgency.

Why this keeps happening now

The deeper pattern is what makes this urgent. A decade old bug got found and weaponized because an AI model was pointed at the kernel’s networking code and told to look. That is going to keep happening, because the cost of this kind of analysis has collapsed. Bugs that sat undiscovered for 10 years are now getting surfaced in batches, and the moment a fix lands in the public kernel tree, the fix itself tells anyone watching exactly where the hole was.

That compresses the safe window to almost nothing. Once CVE-2026–98432 was public with a patch, every day a distribution took to ship that patch was a day its users were exposed with the vulnerability fully documented. In that environment, the distributions that track upstream and ship quickly have a real advantage, and the ones that batch, test, and delay are making a tradeoff that looks worse every time the gap between disclosure and exploit shrinks.

What to actually do about it

If you run Ubuntu servers, check your exposure directly rather than trusting any single take, including this one. Look at Ubuntu’s own CVE page for your release’s current status, run uname -r to see exactly which kernel you are on, and check whether you are on a standard kernel or an HWE kernel, because the proposed fix covers the standard builds and some HWE lines still had no fix listed. Decide deliberately whether to pull the fix from the testing channel now or wait for it to reach normal updates, and weigh that against your actual exposure. If you need patches to land within days of a critical CVE rather than weeks, this incident is a concrete data point for choosing a distribution that tracks upstream closely, whether that is Debian or something similar. Ubuntu being slow here does not make it uniquely broken. The real takeaway is that in a world where a new critical kernel bug can go from disclosure to working exploit in under an hour of machine time, patch speed, and the channel a fix ships to, are features you should evaluate before you commit your infrastructure to a vendor.