CVE-2026-98432: which Linux kernels are still vulnerable

CVE-2026-98432 is a use-after-free bug in the Linux kernel’s IPv4 TCP handshake. Anyone who can send a SYN to a listening port can reach it. Your application never sees a single byte. The bug goes back to Linux 4.4. The upstream fix has been out since mid-October. Ubuntu and Red Hat still haven’t shipped one.

The box I’m typing this on runs Ubuntu 26.04 with kernel 7.0.0-42-generic. That kernel is on the vulnerable list. So this post is also for me. 😬

Fixed upstream kernels#

If you run a kernel.org stable kernel, these are the first fixed releases:

Anything older than those, on that branch, is vulnerable. Distro kernels have their own version numbers and their own backported fixes. For those, check the distro’s own tracker, not uname -r against this table.

Which distributions are still vulnerable#

This is the state on 1 November 2026, from each distribution’s own tracker. It changes daily. Atlas Security’s write-up keeps a running timeline.

• ✔Fixed
• no fixVulnerable, no fixed kernel released

The Debian, Amazon and Oracle UEK kernels have been fixed for days. The two biggest server distributions, Ubuntu and Red Hat, haven’t shipped anything.

For Ubuntu, the fixed linux packages are already named on the tracker : 7.3.0-10.10 for 26.10, 7.0.0-43.43 for 26.04, 6.8.0-149.149 for 24.04 and 5.15.0-203.213 for 22.04. They’re just not released. The cloud kernels (linux-aws, linux-azure, linux-gcp, …) and the HWE kernels each have their own row and their own status there. Look up the kernel you actually boot. 20.04 and older are only covered through Ubuntu Pro. Those rows don’t even say “in progress” yet.

For RHEL, Red Hat says it’s “expediting the release of fixes” in RHSB-2026-016 . That’s all it says. RHEL 6 and 7 aren’t mentioned. AlmaLinux decided not to wait. It built its own fixed kernels (kernel-4.18.0-553.180.2.el8_10, kernel-5.14.0-687.61.2.el9_8, kernel-6.12.0-211.69.2.el10_2). They’re in the testing repo for now. I didn’t check Rocky Linux.

On SUSE, Leap 15.6 is still listed as affected. Tumbleweed isn’t on SUSE’s page at all.

Am I exposed?#

Two quick checks. First, compare your kernel with your distro’s tracker:

$ uname -r
7.0.0-42-generic

On Ubuntu 26.04 the fix will be 7.0.0-43.43. So this one is vulnerable. Second, check whether anything is listening with Multipath TCP (MPTCP). The only known exploit needs an MPTCP listener on the target:

$ sysctl net.mptcp.enabled
net.mptcp.enabled = 1
$ sudo ss -Mlnp | awk 'NR>1{print $6}' | grep -oE '\(\("[^"]+"' | sort | uniq -c
    711 (("tailscaled"
      1 (("whatsapp-mcp"

712 MPTCP listeners. I never asked for a single one. They’re all Go programs. tailscaled has one listener per tailscale serve port, on the tailnet IPv4 and IPv6 address. The other one is a small MCP server on 127.0.0.1. Since Go 1.24, Go turns MPTCP on by default for listening sockets, as long as the kernel allows it. A lot of infrastructure is written in Go these days. Run that ss on your own boxes too.

In my case all of those listen on Tailscale or localhost only. Only devices on my tailnet can reach them. That’s a lot better than the public internet. It’s still not something I’d leave like this.

Blocking it until your distro catches up#

The real fix is a patched kernel and a reboot. Until then, drop every IPv4 TCP packet that carries IP options. Almost no legitimate traffic sets them. The bug needs them. This is the rule AlmaLinux published. It hooks into prerouting, so it runs before anything else touches the packet:

nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop

ip hdrlength counts the IPv4 header in 4-byte words. A header without options is 5 words (20 bytes). Anything above 5 carries options.

I tested it in a throwaway network namespace. A small Python script opens two connections to a local listener. One is plain. The other sets a Record Route option through IP_OPTIONS.

$ sudo ip netns add cve98432
$ sudo ip -n cve98432 link set lo up
$ sudo ip netns exec cve98432 python3 syn.py
plain SYN: connected
SYN with Record Route: connected

Then the same, with the three nft lines above added inside the namespace:

$ sudo ip netns exec cve98432 python3 syn.py
plain SYN: connected
SYN with Record Route: TimeoutError
$ sudo ip netns exec cve98432 nft list table ip cve_2026_98432
table ip cve_2026_98432 {
	chain pre {
		type filter hook prerouting priority raw; policy accept;
		meta l4proto tcp ip hdrlength > 5 counter packets 3 bytes 300 drop
	}
}

Three packets dropped: the SYN and two retransmits. Each is 100 bytes: 20 bytes of IP header, 40 of options, 40 of TCP. The plain connection is untouched.

The rule is in memory only. Save it in /etc/nftables.conf, or it’s gone at the next reboot. (Admittedly, that reboot is also when you’d boot the fixed kernel.) Container traffic that’s bridged on the same host can bypass a prerouting hook on the host. And don’t use it on networks that rely on CIPSO security labels. Those travel as IP options. Red Hat publishes a version on the input hook. It says the rule “reduces exposure to this vulnerability but cannot fully prevent it”. The same goes for every rule here. It’s a temporary measure, not a fix.

You can also turn MPTCP off if you don’t use it. That takes away the path the known exploit uses:

echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/99-no-mptcp.conf
sudo sysctl --system

That only affects sockets created afterwards. Restart the services that listen. It’s also set per network namespace, so containers need it too (docker run --sysctl net.mptcp.enabled=0 ...). I’d still add the nft rule. The bug is in the IPv4 handshake. MPTCP is just the one way in that’s been proven to work.