A serious Linux kernel flaw is fixed on Debian, but not yet on Ubuntu or Red Hat

If you run a Linux server, this kernel flaw is worth ten minutes this week. On Debian the fix is out, so install it and reboot. On Ubuntu and Red Hat there's nothing to install yet, but there's a quick check you can do while you wait.

I can't find any report of attacks using it so far, and it isn't on CISA's list of exploited flaws. What pushed it up my list is a claim, made this week, that it can be turned into remote root.

What happened

The flaw is CVE-2026-98432, and the CVE record was published on 15 October. It's a timing bug in the code that sets up new IPv4 TCP connections, which is the first thing that happens when anyone connects to your server. In the wrong race, the kernel frees a piece of memory while another part of it is still reading it. It goes back to kernel 4.4.

On 27 October Anthropic, the AI company, published a write-up saying its AI model had built a working attack. It says an attacker could send packets to a Linux server with a multipath TCP listener, "without any credentials or user interaction", and end up running a command as root. The proof of concept took 48 minutes to get the first piece of information it needed, and about five more to run a command. A failed attempt doesn't crash the server, so an attacker can keep trying.

The write-up doesn't give the kernel version or setup it was tested on, and I can't check the claim myself. The scores differ too. The kernel's CVE team gives it 9.8 out of 10. Red Hat and SUSE give it 8.1, rating it harder to pull off. Red Hat describes the main impact as a crash, with possible memory corruption.

Either way, a stranger on the internet can reach it without logging in. I wouldn't leave it.

Does it affect you?

You have your own server or rent a virtual one. The kernel is your job.

You run Docker. Containers share the kernel of the server underneath, so for once there's nothing to rebuild. Only the server's kernel matters.

You're on shared hosting or a managed platform. Nothing to do. Your provider runs the kernel.

Where the fixes have got to

When I checked on 30 October:

• Debian. Fixed. The security tracker lists 6.12.113-1 for Debian 13 and 6.1.190-1 for Debian 12. Those are the versions that fixed PwnEscape, so if you did that update and rebooted, you're covered.
• Ubuntu. Not yet. Its CVE page lists 22.04, 24.04 and 26.04 as vulnerable, with fixes in progress but not out yet. 20.04, 18.04 and 16.04 are listed as vulnerable, with no fix in progress shown.
• Red Hat Enterprise Linux. Not yet. Red Hat's data lists 8, 9 and 10 as affected, and 7 as not. If you're on AlmaLinux or Rocky, check their own notices.
• Proxmox. I couldn't find an advisory for this flaw on Proxmox's forum, so keep an eye on it.

What to do this week

1. See what's running. On Debian, compare the number after the word "Debian" with the list above:

uname -rv

2. On Debian, update and reboot. Run sudo apt update && sudo apt full-upgrade, reboot at a quiet time, then run uname -rv again. A new kernel does nothing until the server restarts into it.

3. Look for multipath TCP listeners. The attack Anthropic describes needs one, and you might have one without knowing. The Go 1.24 release notes say its listeners use it by default on Linux, and plenty of modern server software is written in Go. This lists them, with the program behind each:

sudo ss -Mlnp

An empty list isn't an all-clear. The bug itself is in ordinary IPv4 TCP code, and the write-up doesn't say what's possible on a server with no such listener.

4. Consider a stopgap if you've got listeners and no fix. This stops new multipath TCP sockets being created, according to the kernel documentation:

sudo sysctl -w net.mptcp.enabled=0

Restart the services the list showed you and check they still work. The setting doesn't survive a reboot. Red Hat says a mitigation is "either not available" or doesn't meet its criteria, and none of the vendor pages I read offers this as a fix, so treat it as narrowing the risk, not closing it.

5. On Ubuntu or Red Hat, plan the reboot now. Automatic updates will usually install the new kernel when it arrives, but they won't normally reboot for you.

The bigger point

With no fix to install, the job is knowing which servers are exposed and being ready to move when it lands. If nobody in your business is going to watch for that, that's what a support retainer is for. I keep your servers updated, reboot them when they need it, and tell you about it in plain English.