osky

CVE-2026-98432: critical Linux TCP flaw allows remote execution, and Ubuntu and RHEL still have no patch

Sección
Technology

The Linux kernel CVE team published CVE-2026-98432, a use-after-free in the code that sets up incoming IPv4 TCP connections, rated CVSS 3.1 9.8 (critical): it's attacked over the network, with no credentials and no user interaction. The bug has existed since Linux 4.4 and is already fixed in all stable branches, but the patch for your distribution may not have arrived yet. As of November 1, Ubuntu still lists its kernel as vulnerable in all versions, and Red Hat still hasn't published the fix for RHEL 8, 9 and 10. If you manage a Linux server that accepts TCP connections, which is almost any of them, this is about you.

What exactly fails

According to the kernel announcement, when the TCP handshake finishes, the tcp_v4_syn_recv_sock() function hands the new socket the IPv4 options that came with the request without copying them. Meanwhile, another CPU may be processing a retransmitted SYN for the same connection and building a SYN-ACK with those same options. If the connection closes at that moment, the kernel frees the memory with a plain kfree() while the other CPU is still reading it. Reading memory that has already been freed is exactly a use-after-free.

The announcement describes a second, similar case when request socket migration is enabled (net.ipv4.tcp_migrate_req=1 or a BPF migration program). IPv6 doesn't have the first problem because it duplicates the options; a related IPv6 case will be fixed in a separate patch.

Diagram of the race between two CPUs in the IPv4 TCP handshake that causes the use-after-free in CVE-2026-98432, and the change from kfree() to kfree_rcu() that fixes it

The fix, signed by Eric Dumazet, swaps two kfree() calls for kfree_rcu(), which waits until no reader is still using the memory before freeing it. It's in these versions: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3.

Why it's so serious

The vulnerable code runs inside the kernel before any application sees the connection, so it doesn't matter whether your Nginx or your SSH are well configured. AlmaLinux sums it up this way: the trigger is a SYN with IPv4 options sent to a listening TCP port.

Anthropic, whose researcher Xinyang Ge reported the bug, published that Claude wrote an exploit that allows running commands as root on Linux servers with a Multipath TCP (MPTCP) listener, with no credentials. According to Anthropic, losing the race only makes the handshake fail without bringing the system down, so the attacker can retry without limit. In their proof of concept it took 48 minutes to leak a kernel pointer and five more minutes to get to running commands. Anthropic has not published the exploit.

The MPTCP detail matters more than it seems. The Go security team warned that, since Go 1.24, Go programs open their listening sockets with MPTCP by default on Linux if the kernel allows it. And it clarified that the bug is not exclusive to MPTCP: systems without those listeners could be vulnerable to similar attacks.

How each distribution is doing

What counts is your distribution's kernel, not the upstream version number:

Distribution Status as of November 1
Debian 12 and 13 Fixed (6.1.190-1 and 6.12.113-1, in the security repository)
Ubuntu 16.04 to 26.10 Vulnerable; fix in progress for 22.04, 24.04, 26.04 and 26.10
RHEL 8, 9 and 10 Affected; Red Hat says it is accelerating the patches
AlmaLinux 8, 9 and 10 Fixed kernels in the testing repository since October 30

Red Hat rated the bug as critical and warns that any product that uses its kernel, including RHEL CoreOS, may be affected. Ubuntu gives it high priority.

What to do today

This comes from the Red Hat, AlmaLinux and Go team advisories. I didn't test it on a production server.

  1. Check your kernel with uname -r and compare it against your distribution's tracker. On container hosts and Kubernetes nodes, check it on the host: containers use the machine's kernel.
  2. Update and reboot as soon as the patch exists. Without a reboot, the new kernel doesn't run.
  3. While there's no patch, Red Hat and AlmaLinux published an nftables rule that drops IPv4 TCP packets carrying IP options (ip hdrlength > 5). Normal traffic almost never uses them. Red Hat notes that the rule "reduces exposure… but cannot fully prevent it", and AlmaLinux warns that traffic between containers on the same host can bypass it and that it shouldn't be used on networks that depend on CIPSO labels.
  4. Look for MPTCP listeners with ss -Mlnp. If you don't use MPTCP, AlmaLinux suggests turning it off with net.mptcp.enabled = 0 and restarting the services that already had it open. For a specific Go program there's GODEBUG=multipathtcp=0, although the Go team itself calls it a fragile mitigation.

My take

A ten-year-old bug in the busiest path of the kernel, found and turned into an exploit by an AI model, with a four-line patch that took weeks to reach the big distributions: that's the real news. The time between an upstream patch being published and an attacker turning it into an exploit is shrinking, and the bottleneck is no longer finding the bug, but your reboot window. If your server runs Ubuntu or RHEL, put the nftables rule in place today and schedule the reboot for when the kernel arrives.

Sources