CVE-2026-98432 (CVSS 9.8): Linux Kernel TCP Use-After-Free Enables Remote Root — Is Your Server Patched?

A critical use-after-free vulnerability in the Linux kernel’s IPv4 TCP stack has security teams across the globe scrambling this week. CVE-2026-98432, scored CVSS 9.8 (Critical) by both the Linux kernel CNA and Red Hat, allows an unauthenticated remote attacker to trigger a memory corruption condition during TCP connection establishment — potentially achieving arbitrary code execution with root privileges on the target host. With Red Hat raising its own severity rating to 9.8 on October 30 and patches still pending for Ubuntu as of November 2026, the window of exposure for millions of enterprise Linux servers remains wide open. If your SOC or infrastructure team has not yet acted, now is the moment.

What Is CVE-2026-98432?

CVE-2026-98432 is a use-after-free (UAF) race condition in the Linux kernel’s IPv4 TCP connection handling code, specifically in the inet_sock_destruct() and tcp_v4_reqsk_destructor() functions. When a TCP connection is torn down under specific timing conditions, the kernel frees memory via kfree() at a point where another kernel thread may still hold a reference to that memory. The result is a classic UAF — a dangling pointer that can be targeted by an attacker to overwrite kernel memory structures, pivot to arbitrary code execution, and gain root.

The flaw has been present in the kernel since version 4.4, meaning virtually every enterprise Linux deployment built on kernels from that era forward is potentially vulnerable. The fix is elegantly small: replacing kfree() with kfree_rcu() in both affected functions ensures the memory is only freed after any RCU-protected references have been released — but rolling that fix through enterprise distributions takes time, and the exposure window is real.

This kind of kernel-level vulnerability is especially dangerous in NOC/SOC environments where Linux underpins monitoring servers, log aggregators, SIEM collectors, and packet-capture appliances — machines that by design accept inbound network connections and process raw TCP traffic. As covered in our earlier analysis of the Ivanti Connect Secure zero-day chain, network-layer vulnerabilities on infrastructure components can pivot quickly into full enterprise compromise.

Technical Deep Dive: The TCP Use-After-Free Race

To understand the severity, consider what happens during a standard TCP three-way handshake in the kernel. When a client sends a SYN packet, the kernel allocates a request socket (inet_request_sock) to track the half-open connection. When the connection is aborted or times out, tcp_v4_reqsk_destructor() is called to clean up. The race window opens when:

1. Thread A calls kfree() on the request socket — the memory is returned to the kernel allocator.
2. Thread B, still executing in the interrupt or softirq context, dereferences a pointer into that now-freed memory.
3. An attacker who can influence the kernel heap layout positions a controlled allocation in the freed slot, redirecting the dereference to attacker-controlled data.

Critically, no authentication is required. Any system accepting inbound IPv4 TCP connections is exposed. IPv6 TCP connections are not affected because the kernel copies IPv6 TCP options into a different structure, eliminating the race window for that path.

Servers where MPTCP (Multipath TCP) is enabled may have a broader attack surface because MPTCP’s path management adds additional concurrent context switches around the same socket structures. Notably, applications built with Go 1.24 or later enable MPTCP by default on Linux — a subtle but important detail for organisations running Go-based microservices or cloud-native infrastructure.

The upstream fix — documented in stable releases 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, and 7.2.10 — is confirmed by the Akamai security research team and tracked in Red Hat’s official security bulletin RHSB-2026-016.

Affected Distributions and Patch Status

The following table reflects the state of patches as of November 3, 2026. Always verify against your vendor’s official advisory before making decisions:

Distribution	Status	Details
RHEL 8, 9, 10	✓ Fixed	RHSA-2026:93412/93413/93414, released Nov 1, 2026
Ubuntu 20.04 / 22.04 / 24.04 LTS	⚠ Pending	In -proposed as of Oct 26; Livepatch not yet available
Debian 12 (Bookworm)	✓ Fixed	6.1.190-1 or 6.12.113-1~deb12u1
Debian 13 (Trixie)	✓ Fixed	6.12.113-1
Amazon Linux 2 / 2023	✓ Fixed	Default kernel updated
Oracle Linux UEK	✓ Fixed	Per vendor advisory
SUSE Linux Micro 6.0 / 6.1	✗ Not Fixed	Awaiting vendor fix; apply mitigations
Rocky / AlmaLinux	⚠ Verify	Track against RHEL upstream fix; check vendor errata

What You Should Do Right Now: Expert Checklist

As a practitioner managing Linux infrastructure across hybrid environments and cloud-connected NOC/SOC deployments, here is the prioritised response plan:

1. Inventory your kernel versions immediately. Run uname -r across your fleet or query your CMDB. Any kernel older than the fixed version for your distro is at risk. Kubernetes nodes, CI/CD runners, and hypervisor hosts running Linux are equally affected — prioritise network-exposed systems first.
2. RHEL shops: apply RHSA-2026:93412/93413/93414 now. Red Hat published the advisory on November 1, 2026. Use your standard patching workflow but treat this with the urgency of an emergency change window. Reference Red Hat RHSB-2026-016 for the official guidance.
3. Ubuntu shops: apply the interim mitigation. Since the Ubuntu kernel fix is still in -proposed, disable MPTCP immediately:

   sysctl -w net.mptcp.enabled=0

   Note that disabling MPTCP reduces but does not eliminate the attack surface — the base IPv4 TCP race still exists. Additionally, consider an nftables rule to drop inbound IPv4 packets carrying IP options:

   nft add rule inet filter input ip frag-off 0 ip options exists drop

   Test this rule in your environment first — some legitimate applications rely on IP timestamp or record-route options.

4. Place TCP-terminating proxies in front of exposed services. L4 (pass-through) load balancers do not protect the backend hosts — the kernel on those hosts still processes the raw TCP handshake. Only L7 or TCP-terminating proxies (HAProxy, NGINX, cloud load balancers) that fully terminate TCP protect backend hosts from this exploit path.
5. Audit Go-based services. Applications built with Go 1.24 or later enable MPTCP by default on Linux. Identify and reconfigure those services as a temporary measure until the kernel patch is applied.
6. Monitor for exploitation indicators. Look for unusual kernel panic logs, high-volume unexpected TCP resets, or processes gaining unexpected root privileges. Correlate with your SIEM or SOC dashboard for anomalous kernel-mode activity.

The Zero-Trust Lens: Why Network Segmentation Matters

CVE-2026-98432 is a potent reminder of why zero-trust network architecture is not optional for modern enterprises. This vulnerability requires only that an attacker can reach your server’s TCP port — a condition trivially met if your perimeter firewall is the only control between the attacker and your server. In a zero-trust model, every server sits behind micro-segmentation policies that allow only specifically enumerated source IP ranges and ports. That doesn’t prevent exploitation if an attacker is already inside the network, but it dramatically shrinks the blast radius and limits lateral movement.

As explored in Sanjay’s detailed write-up on zero-trust campus design with FortiGate and FortiAuthenticator, even physical network architecture decisions — VLAN segmentation, east-west firewall policies, and strict ACLs on server-facing interfaces — matter enormously when a kernel-level flaw exposes the TCP stack of every machine on a segment.

For Indian enterprises — particularly those in BFSI, government, and critical infrastructure sectors — this is especially relevant given the increasing frequency of targeted attacks on exposed server infrastructure. CERT-In advisories for critical kernel flaws should be on your watch list; advisories tracking CVE-2026-98432 are expected to follow closely on the Red Hat bulletin cycle.

Frequently Asked Questions

Does CVE-2026-98432 require an open port or running service to exploit?

Yes — the attacker must be able to reach a listening TCP socket on the vulnerable host. Any Linux server accepting inbound IPv4 TCP connections is in scope, regardless of which application is listening. This includes SSH (port 22), web servers (80/443), database listeners, or any custom application. Hosts that accept only IPv6 connections are not affected by this specific flaw.

Is CVE-2026-98432 being actively exploited in the wild?

As of November 3, 2026, there are no confirmed public reports of in-the-wild exploitation. However, the vulnerability is being widely analysed by security researchers, and exploit development is known to be underway in the research community. The complexity of reliably triggering a remote kernel heap UAF keeps the bar high for most threat actors — but sophisticated APT groups and state-sponsored actors should be assumed capable. Apply patches and mitigations without waiting for confirmed exploitation — the CISA KEV catalog is the most reliable signal to watch.

Are containerised workloads (Docker, Kubernetes) affected?

Yes. Containers share the host kernel, so all containerised workloads running on a vulnerable Linux host are exposed. The vulnerable code path is in the kernel’s TCP stack, not in user space. This means every Kubernetes node and every Docker host running a vulnerable kernel is in scope — including those running otherwise hardened container images. Patch the host kernel; a patched container image provides no protection against this flaw.

How serious is this for India’s IT and cloud-native landscape?

Very serious. India is one of the world’s fastest-growing consumers of Linux-based server infrastructure, particularly in AWS, Azure, and GCP cloud environments — all of which run Linux under the hood. With Digital India initiatives, government e-services, and BFSI digital banking running on Linux at scale, any CVSS 9.8 unauthenticated RCE-class kernel flaw demands immediate board-level awareness and an emergency patch window. CISOs should update their risk registers and brief leadership now, before a proof-of-concept becomes a weaponised exploit.

Conclusion: Patch and Harden in Parallel

CVE-2026-98432 is a stark example of how a small coding oversight — using kfree() instead of kfree_rcu() — can sit silently in billions of production servers for years before a researcher pulls the thread. The lesson for security teams: kernel patching must be treated as a first-class priority, not a maintenance afterthought. Pair that with network controls that limit who can reach your TCP listeners, and you significantly reduce your exposure even before a patch lands.

Not sure if your Linux infrastructure is fully patched and hardened against emerging kernel-level threats? Request a security assessment from Sanjay Seth — covering kernel patch management, zero-trust network segmentation, NOC/SOC readiness, and enterprise vulnerability management for your environment in Delhi NCR and beyond.