Critical Linux TCP vulnerability CVE-2026-98432 requires immediate patching

Linux stable kernels received a critical security fix in mid-October 2026 for CVE-2026-98432, a use-after-free vulnerability in the IPv4 TCP handshake. The flaw allows a remote, unauthenticated attacker to execute arbitrary code with root privileges on affected servers. While upstream maintainers have resolved the issue, many major enterprise distributions remain vulnerable as of late October.

What happened

The Linux kernel community assigned CVE-2026-98432 a CVSS 3.1 score of 9.8, marking it as Critical. The vulnerability exists in the code path that handles incoming IPv4 TCP connections, specifically during the initial handshake before any application-level authentication occurs. The bug was reported by Xinyang Ge from Anthropic and fixed by Eric Dumazet, with the patch reviewed by Kuniyuki Iwashima.

Upstream stable kernels shipped the fix between October 11 and October 15, 2026. Affected versions include long-term support branches such as 5.10, 5.15, 6.1, 6.6, and 6.12, as well as newer mainline releases. The vulnerability traces back to Linux 4.4, meaning nearly every active Linux server is potentially exposed if it has not received the specific patch. Branches that reached end-of-life before version 5.10 do not have an upstream fix and rely entirely on distribution-specific backports.

Despite the availability of upstream fixes, the deployment status across major distributions is uneven. As of October 31, 2026, Ubuntu’s security tracker lists every release as "Vulnerable," with fixes still in progress for recent versions. Red Hat Enterprise Linux (RHEL) 8, 9, and 10 are also listed as affected with no fix available, though Red Hat has raised its severity rating to Critical. AlmaLinux has fixed kernels in testing, while Debian, SUSE, Oracle, and Amazon Linux have already released patches for their supported versions.

How it works

The vulnerability stems from a race condition in how the kernel manages memory for TCP connection options. When a server accepts a TCP connection, it creates a lightweight "request socket" to track the half-open handshake. If the connecting client includes IPv4 header options, the kernel stores them to echo in subsequent replies. The bug occurs because the kernel passes these option pointers to the new full socket without copying the data, then immediately frees the original request socket memory.

If another CPU core is still reading those options to build a reply while the memory is being freed, a use-after-free condition occurs. This can lead to kernel heap memory disclosure, memory corruption, or a system crash. Anthropic researchers demonstrated that this race condition can be exploited to achieve remote code execution. Notably, their proof-of-concept exploit targeted servers with Multipath TCP (MPTCP) listeners, which are enabled by default in Go programs starting with version 1.24. However, the underlying bug is not exclusive to MPTCP, and other configurations may also be vulnerable.

The fix is minimal, consisting of a four-line change that replaces standard memory free calls with kfree_rcu(). This function ensures that memory is only freed after all readers have finished accessing it, preventing the race condition. The patch also addresses similar issues in request-socket migration paths.

Key details

• CVE Identifier: CVE-2026-98432, scored 9.8 Critical by the Linux kernel CNA.
• Vulnerability Type: Use-after-free in IPv4 TCP handshake option handling.
• Affected Systems: Linux kernels from 4.4 onwards that accept IPv4 TCP connections.
• Exploit Status: A working remote root exploit exists for servers with MPTCP listeners, developed by Anthropic.
• Distribution Status: Fixed in Debian, SUSE, Oracle, and Amazon Linux; pending for Ubuntu and RHEL as of October 31, 2026.
• Mitigation: Network-level filtering of IPv4 packets with options can reduce exposure until patches are applied.

Why it matters

For infrastructure engineers and platform teams, this vulnerability represents a high-risk scenario because it requires no authentication and operates at the network stack level. Since the exploit occurs before application code runs, traditional web application firewalls or service-level authentication mechanisms cannot prevent it. The fact that major distributions like Ubuntu and RHEL have not yet released fixes leaves a significant portion of enterprise infrastructure exposed during this window.

The involvement of MPTCP adds complexity to risk assessment. With Go 1.24 enabling MPTCP by default, many modern microservices and cloud-native applications may inadvertently expose their hosts to the most easily exploitable configuration. Teams running Go-based services on Linux must verify their kernel status and consider disabling MPTCP if they cannot patch immediately. The delay in distribution-level fixes means that proactive mitigation strategies, such as network filtering, are essential for maintaining security posture.

What you can do

• Check your running kernel version using uname -r and compare it against your distribution’s security advisory to see if a fix is available.
• If a fixed kernel is installed, reboot your servers to activate the patch, as kernel updates do not take effect until restart.
• For systems that cannot be patched yet, implement nftables or iptables rules to drop incoming IPv4 TCP packets containing IP options, which blocks the attack vector.
• Disable Multipath TCP by setting net.mptcp.enabled = 0 in sysctl if your applications do not explicitly require it, reducing the attack surface.
• Monitor your distribution’s security tracker for updates, particularly if you run Ubuntu or RHEL, as fixes are expected soon.
• Verify if any listening services are using MPTCP by running ss -Mlnp and restart those services after disabling MPTCP to ensure the change takes effect.