Linux kernel TCP handshake use-after-free CVE-2026-98432 fixed with RCU-delayed frees

A use-after-free in the Linux kernel's IPv4 TCP handshake path, tracked as CVE-2026-98432, can leave one CPU reading IP options memory that another CPU has already released. The upstream fix, merged as commit e3f33b0a1d89, delays reclamation of those objects until an RCU grace period has elapsed, and the analysis that surfaced the issue stresses that operators should validate their patched builds rather than trust kernel version strings.

How the race happens

According to a write-up on Penligent, a TCP server answers an incoming SYN with a compact request socket instead of a full connection, keeping resource costs low while the handshake is in progress. When the handshake completes, tcp_v4_syn_recv_sock() hands the request's ireq_opt pointer over to the newly created child socket as inet_opt — a transfer, not a copy.

While that happens, a second CPU can be handling a retransmitted SYN for the same request and sending a fresh SYN-ACK through tcp_check_req(). That path consults the request's IP options inside an RCU read-side critical section, via helpers such as tcp_v4_send_synack(), inet_csk_route_req() and ip_options_build(). The lifetime mismatch is the flaw: the reader behaves as though RCU protects the object, but the destructor releases it with plain kfree(), which permits immediate reuse. If the child socket is torn down while the retransmit path is mid-flight, that CPU keeps dereferencing memory that no longer belongs to the options object.

The patch moves both inet_sock_destruct() and tcp_v4_reqsk_destructor() to kfree_rcu(). It also covers a request-migration variant: with net.ipv4.tcp_migrate_req=1, or when a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program steers migration, a cloned request can briefly share the options object with its parent, and a CPU holding the old request can outlive the clone's release.

The core ownership bug is IPv4-specific. The corresponding IPv6 function duplicates the options instead of moving the pointer, so the ordinary IPv6 child-creation path is not affected — though the upstream text flags a separate IPv6 concern around ipv6_opt when CALIPSO labeling is present, handled elsewhere.

Three readings of severity

The CVE record carries a CVSS 3.1 base score of 9.8, describing an unauthenticated, network-reachable worst case with high impact on confidentiality, integrity and availability. Red Hat's product analysis, as reported by Penligent, scores it 5.9, treating exploitation as a hard-to-win race and weighing consequences on its supported builds more conservatively. Anthropic's Frontier Red Team, meanwhile, demonstrated a working remote-root code-execution chain against a Linux server with a Multipath TCP listener in a controlled lab.

Penligent's framing is that these are complementary data points, not contradictions: the upstream record defines the memory-lifetime error and its theoretical ceiling, the vendor score reflects shipped code and expected conditions, and the exploit proves one concrete path. Discarding any of them, or stretching any beyond its scope, misleads.

What remains unproven

No cited source shows exploitation across the public internet. The lab result does not establish how common vulnerable MPTCP listeners are, a general success rate, or that the same chain ports cleanly across kernel builds, CPU architectures, allocators and hardening profiles. Heavy SYN retransmission traffic, which occurs naturally from packet loss, overloaded services and client retries, is likewise not evidence of an attack on its own; it needs correlation with a vulnerable host and kernel symptoms.

Validating the patch

The recommended response is operational: inventory internet-facing Linux networking hosts — gateways, load balancers, Kubernetes nodes, VPN endpoints, reverse proxies and appliances — with MPTCP listeners first in line, then install the vendor's fixed build, reboot, and keep evidence that the running kernel contains the correction. Debian's security tracker maps the issue to fixed packages, and Ubuntu's CVE page tracks each kernel flavour separately, which underlines the article's point that uname -r comparisons against upstream releases yield both false positives and false negatives. A vendor advisory, package changelog, build metadata, VEX statement or confirmed backport of the fix commit is the defensible proof.

Disabling MPTCP strips away the exact configuration used in the research chain and can reduce near-term exposure, but the underlying IPv4 lifetime bug spans the ordinary request and child socket paths as well. Patching remains the durable correction.

Why it matters

The defect sits in kernel code reached by ordinary traffic before any authentication completes, so exposure is a function of having a reachable TCP listener, not of a weak application. The remote-root demonstration on an MPTCP host shows the bug is more than a crash vector, while the gap between a 9.8 and a 5.9 score is a reminder that a single number cannot drive a patch decision. And the validation guidance generalises: because distributions backport fixes onto old-looking versions, evidence-based confirmation is the only reliable signal that a fleet is protected.