CVE-2026-98432: Linux TCP Use-After-Free Risk and Patch Validation

The vulnerability also has a related request-migration case. If net.ipv4.tcp_migrate_req=1 is enabled, or if a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program controls request migration, the kernel may clone a request socket. The old request and its clone can temporarily share the same options object. A CPU holding a reference to the old request can still use the object while the clone is freed. The kernel description therefore changes both inet_sock_destruct() and tcp_v4_reqsk_destructor() to use RCU-aware reclamation.

The first issue is specific to the IPv4 child-socket path because the corresponding IPv6 function duplicates options instead of transferring the same pointer. The upstream text also notes an IPv6 request-migration concern involving ipv6_opt when CALIPSO is present and says that condition is handled separately. That distinction matters: a statement that “IPv6 is unaffected” is too broad, while a statement that the main IPv4 ownership-transfer bug does not apply to the ordinary IPv6 child creation path is accurate.

The patch was merged upstream as commit e3f33b0a1d89, titled “ipv4: free inet_opt and ireq_opt after an RCU grace period.” The Ubuntu CVE page identifies the same introduction and fix commits and tracks many Ubuntu kernel flavors independently. This is useful evidence that a generic kernel version check cannot replace distribution-specific status.

No authoritative source cited here establishes widespread exploitation across the public internet. Anthropic established that its researchers could turn the flaw into remote root command execution against a controlled target with an MPTCP listener. That is stronger than a crash-only proof and should influence urgency. It still does not provide a measured prevalence of vulnerable MPTCP services, a universal success rate, or proof that the same exploit chain works unchanged across kernel builds, CPU architectures, allocators, hardening profiles, and network paths.

The public material also does not justify assuming that any high volume of SYN retransmissions is exploitation. Retransmitted SYN packets occur naturally because of packet loss, asymmetric routing, overloaded services, client retry behavior, and middleboxes. Exploitation of a race may generate unusual patterns, but those patterns need correlation with a vulnerable host, relevant options, kernel symptoms, and timing. A network alert can prioritize investigation; it cannot prove a use-after-free occurred inside the kernel.

There is no single upstream version string that accurately labels every vendor kernel. Enterprise distributions routinely backport security fixes while retaining an older-looking base version. Cloud providers and appliance vendors may ship their own kernel builds. A scanner that compares only uname -r against an upstream release list can produce both false positives and false negatives. The defensible conclusion comes from a vendor advisory, package changelog, build metadata, VEX statement, or direct confirmation that the relevant fix commit was backported.

Finally, disabling MPTCP does not remove the underlying IPv4 lifetime bug. It removes the exact listener configuration used in the public research chain and can meaningfully reduce immediate exposure where MPTCP is unnecessary. The upstream technical description covers the ordinary IPv4 TCP request and child socket paths as well as request migration. Patch deployment remains the durable correction.

A TCP server normally receives a SYN, replies with SYN-ACK, and waits for the final ACK. The kernel avoids allocating a complete connected socket at the first packet because an attacker could otherwise exhaust resources cheaply. Instead, it creates a compact request socket that stores enough state to validate and complete the handshake. When the ACK arrives and the connection is accepted, the kernel creates a full child socket and moves or copies selected state into it.

IPv4 options complicate that transition. IP options can carry metadata that influences routing or packet processing. The kernel parses the incoming information and stores an internal representation for later response construction. In the affected path, the request socket’s ireq_opt pointer becomes the child socket’s inet_opt pointer. The transfer avoids a copy, but it means the lifetime of one allocation crosses the boundary between two socket objects.

A second SYN for the same connection tuple can arrive before the handshake state has completely settled. Retransmission is a normal part of TCP. The kernel may process that SYN on another CPU and build a SYN-ACK using the original request socket. Since Linux networking is highly parallel, the child socket can progress toward teardown while the other CPU is still constructing the reply. The request path takes an RCU read lock, indicating that the data it reads must remain valid until the read-side critical section ends.

The old destructor behavior violated that expectation. The child socket did not carry the SOCK_RCU_FREE behavior that would defer its entire release, and inet_sock_destruct() freed inet_opt directly. The second CPU could retain the pointer and read optlen from memory that had already returned to the allocator. A later allocation could place unrelated data at that address, changing the value between reads or letting subsequent code operate on attacker-influenced contents.

Use-after-free bugs are dangerous because the immediate symptom depends on what replaces the freed allocation. The stale access may read the old bytes and appear harmless. It may encounter poisoned or unmapped memory and crash. It may read a new kernel object and disclose data. With sufficient control over allocation patterns and timing, a researcher may turn the stale reference into a more powerful read, write, or control-flow primitive. The vulnerability class therefore supports outcomes ranging from intermittent handshake failure through denial of service to code execution, but a specific outcome must be demonstrated for a specific target.

The request-migration variant follows the same lifetime principle through a different topology. Reuseport allows multiple sockets to share a listening port, and BPF can participate in choosing a target. Request migration may move pending connections when a listener changes state. The kernel clones request state, creating a window in which two request objects refer to the same options allocation. Clearing the pointer in one object does not protect a CPU that already holds a reference to it. If the other object’s destructor immediately frees the shared allocation, that reader becomes stale.

The patch does not attempt to serialize every operation behind one global lock. That would harm scalability in a hot network path. It instead aligns reclamation with the synchronization model that readers already use. This is precisely the kind of problem Read-Copy Update is designed to solve.

Read-Copy Update lets readers access shared data with very low overhead while writers publish replacements and defer freeing old versions. A reader enters an RCU read-side critical section, obtains a pointer, uses the object, and exits. A writer can remove the object from the data structure so new readers no longer find it, but it must wait for a grace period before reclaiming memory. A grace period ensures that all readers that could have seen the old pointer have finished.

The Linux kernel’s RCU documentation describes the essential removal-and-reclamation split. Removal changes reachability. Reclamation returns storage to the allocator. Conflating those operations is a common source of use-after-free errors. An RCU lock does not place a reference count on an arbitrary object and does not make direct kfree() safe. The corresponding writer must use an RCU-aware mechanism such as call_rcu() or kfree_rcu().

In CVE-2026-98432, the read paths already use RCU. The correction makes the destructor honor that contract. kfree_rcu() schedules the object for release after a grace period rather than releasing it immediately. The CPU building the SYN-ACK can finish reading the old options object. Later readers will no longer obtain it, and the allocation becomes reusable only after the preexisting readers are gone.

This design preserves concurrency. It does not require the server to stop processing retransmissions, place a large lock around handshake construction, or copy the options object for every read. The security property is narrow and clear: an object visible to an RCU reader remains allocated for the duration in which that reader might access it.

RCU fixes also explain why packet filtering alone cannot be a complete remedy. The memory-safety defect is in object lifetime management. Filtering may make a trigger harder to reach, and disabling unneeded features can reduce the set of paths. Only corrected reclamation restores the invariant for every legitimate and hostile packet that reaches the code.

The CVE record’s CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, producing 9.8. This vector assumes a network attacker needs no account and no user interaction, that attack complexity is low, and that successful exploitation can have high impact across confidentiality, integrity, and availability. It expresses the CNA’s base characterization of the vulnerable upstream component.

Ubuntu displays that 9.8 value but also publishes a CVSS 4.0 assessment of 8.3 with attack requirements present. CVSS 4.0 can represent prerequisites that do not fit cleanly into the older vector. Ubuntu’s page labels the vulnerability high priority and exposes package-by-package states rather than treating the numeric score as the entire decision.

Red Hat’s 5.9 score reflects a different assessment. Red Hat evaluates vulnerabilities in the context of its products, backports, default configurations, mitigations, and likely consequences. Its analysis treats the race as high complexity and emphasizes that a reliable security impact may be a crash or denial of service, while memory corruption and stronger outcomes depend on additional conditions. A lower vendor score does not mean the upstream bug is imaginary; it means the vendor does not accept every worst-case metric for the products it ships.

CVSS disagreement is common for open-source components distributed in different forms. The same source defect may be present in two products but exposed through different configurations. One vendor may enable a feature by default, another may omit it, and a third may carry a partial backport that changes reachability. Kernel hardening, allocator behavior, architecture, compiler options, and service topology can all affect exploit development without changing the vulnerable source line.

For operational prioritization, a single universal score is less useful than a short environment-specific analysis:

The 9.8 score is useful for recognizing the potential ceiling. The 5.9 score is useful for understanding Red Hat’s product-specific view. Neither number should override the fact that an exposed MPTCP target was exploited in a lab, and the lab result should not be converted into a claim of mass exploitation. Defenders can act urgently while preserving those distinctions.

Anthropic’s October 27 research post describes a remote, zero-click Linux kernel exploit against a server with a Multipath TCP listener. According to the researchers, the exploit used the race-induced use-after-free in two stages. The first stage obtained a kernel pointer and defeated Kernel Address Space Layout Randomization. The second stage converted the memory corruption into control-flow hijacking and ultimately ran an attacker-chosen command as root.

The team reports that its proof of concept took approximately 48 minutes to disclose a kernel pointer and another five minutes to reach command execution. A failed attempt could leave the handshake incomplete without necessarily crashing the host, allowing repeated trials. That b