Red Hat has fixed the Linux TCP flaw. Ubuntu is still waiting, so here's a stopgap

If you run Red Hat Enterprise Linux, there's now a kernel fix for the TCP flaw I wrote about on Friday. Install it and reboot this week. If you're on Ubuntu, there's still nothing to install, but there's now a firewall rule you can put in while you wait.

I also need to correct something from last time. More on that below.

What's changed

The flaw is CVE-2026-98432, a timing bug in the code that sets up new IPv4 TCP connections. Anyone who can reach an open port on your server can reach it, without logging in.

On 1 November Red Hat released fixed kernels for RHEL 8, 9 and 10. Its CVE page now rates the flaw Critical, up from the 8.1 out of 10 I quoted last week, and scores it 9.8. Red Hat says ordinary IPv4 TCP traffic can corrupt kernel memory or crash the server, and that default TCP services are exposed. It also says reliable code execution would need "precise heap control", which is a polite way of saying it's hard but not impossible.

I still can't find any report of attacks, and when I checked this morning it wasn't on CISA's list of exploited flaws.

The correction

Last time I suggested turning off multipath TCP as a stopgap, because that's what the attack Anthropic described relies on. CIQ, the company behind Rocky Linux support, tested this and says turning it off doesn't close the path. Plain TCP listeners still answered the problem packets.

AlmaLinux says any system "that accepts IPv4 TCP connections from untrusted networks should be treated as exposed". So if your server has a website, mail or SSH open to the internet, that's you. Turning multipath TCP off does no harm if you don't use it, but don't count it as protection.

Where the fixes have got to

When I checked on 2 November:

• Red Hat Enterprise Linux. Fixed. The kernels are 4.18.0-553.182.1.el8_10 for RHEL 8, 5.14.0-687.64.1.el9_8 for RHEL 9 and 6.12.0-211.72.1.el10_2 for RHEL 10, according to Red Hat's data.
• Debian. Fixed, as before. 6.12.113-1 for Debian 13 and 6.1.190-1 for Debian 12, on the security tracker.
• AlmaLinux. Fixed kernels went into its testing repository on 30 October, ahead of Red Hat. Run an update and see whether a newer kernel turns up from the normal repositories.
• Rocky Linux. CIQ's page lists fixes for some of its paid long-term support versions, but none yet for community Rocky 8.10, 9.8 or 10.2. It recommends the firewall rule for those.
• Ubuntu. Not yet. Its CVE page still shows 22.04, 24.04 and 26.04 as work in progress, and 20.04, 18.04 and 16.04 as vulnerable with nothing in progress.

What to do this week

1. On Red Hat or Debian, update and reboot. On Red Hat that's sudo dnf update 'kernel*', on Debian sudo apt update && sudo apt full-upgrade. Reboot at a quiet time, then check you're on the new kernel:

uname -r

A new kernel does nothing until the server restarts into it.

2. On Ubuntu, or anything else still waiting, add the firewall rule. Red Hat, AlmaLinux and CIQ all publish versions of the same idea. It drops incoming IPv4 TCP packets that carry "IP options", an old part of the packet header that normal traffic rarely uses. This is the AlmaLinux version, because it also covers traffic going to Docker containers in the usual setup:

sudo nft -f - <<'EOF'
add table ip cve_2026_98432
delete table ip cve_2026_98432
table ip cve_2026_98432 {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength > 5 counter drop
    }
}
EOF

If the nft command isn't there, install the nftables package first. Check the rule is in place, and how many packets it has dropped, with:

sudo nft list table ip cve_2026_98432

3. Know what the rule doesn't do. It doesn't survive a reboot, so run it again after one until the fixed kernel is in. AlmaLinux says traffic between containers on the same server may get past it. Red Hat says it "cannot fully prevent exploitation" and could break anything that relies on IP options, so test it if you can. Every vendor that publishes it says the same thing: this isn't a fix.

4. Take the rule out once you're patched.

sudo nft delete table ip cve_2026_98432

If you're on shared hosting or a managed platform, none of this is your job. Your provider runs the kernel.

If you've got apps on these servers

Rebooting a server is easy. Making sure everything on it comes back afterwards is the bit that catches people out, especially with a bespoke app that somebody set up years ago. If nobody's sure what happens to yours when the server restarts, the team at Dev Partners looks after that sort of thing.

The bigger point

This is my second post on this flaw in four days, and it won't be the last until Ubuntu ships. That's what patching looks like in practice: checking back, putting stopgaps in, then remembering to take them out. If nobody in your business is going to do 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.