CVE-2026-98432: use-after-free flaw in Linux TCP exposes remote root via MPTCP

CVE-2026-98432 is a use-after-free flaw in the IPv4 path of the Linux kernel's TCP handshake, documented through the Linux project's own CVE process and detailed by the Penligent Security Blog on October 30, 2026. The upstream record received a CVSS 3.1 score of 9.8, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: network attack, no authentication, no user interaction, with high impact on confidentiality, integrity, and availability.

The problem lies in how the kernel manages the lifecycle of IP options associated with a request socket during the handshake. This matters because the flaw doesn't require any exotic configuration: it sits on the default path for handling TCP connections, which runs on practically every Linux server exposed to the internet, including gateways, load balancers, Kubernetes nodes, and VPNs.

Where the bug lives in the handshake

When a client initiates a connection, Linux doesn't immediately allocate a full socket: it creates a lightweight request socket to validate the handshake before committing memory to a real connection. When the exchange completes, the tcp_v4_syn_recv_sock() function transfers the ireq_opt pointer from the request socket to the inet_opt field of the child socket, without duplicating the IP options object.

The problem appears when a second retransmitted SYN for the same connection arrives while this process is underway. This path runs on another CPU, inside an RCU read-side critical section, through tcp_check_req(), tcp_v4_send_synack(), and inet_csk_route_req(). Later functions, such as ip_build_and_send_pkt() and ip_options_build(), read fields from that same options object that the first path may have already freed.

The original destructor called kfree() directly on that object, as if no RCU reader could be in progress. This is exactly the opposite of what the kernel's own RCU documentation prescribes: removing data from a structure and freeing its memory are distinct operations, and conflating them is a classic source of use-after-free. The fix, merged upstream as commit e3f33b0a1d89 ("ipv4: free inet_opt and ireq_opt after an RCU grace period"), replaces kfree() with kfree_rcu() in the inet_sock_destruct() and tcp_v4_reqsk_destructor() destructors, deferring the free until the end of the RCU grace period.

A second door: request migration

There's a variant of the same bug tied to migrating pending connections between listening sockets. With net.ipv4.tcp_migrate_req=1 enabled, or with a BPF program using BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, the kernel can clone a request socket, and for an instant, two request objects share the same IP options block. If one of their destructors frees that block immediately, a CPU that still holds a reference to the original object ends up reading already-reused memory. The fix extends the same kfree_rcu() logic to this scenario, affecting anyone using SO_REUSEPORT with BPF-based socket selection, common in high-concurrency architectures.

Remote root proven in the lab with MPTCP

On October 27, 2026, researchers at Anthropic published a demonstration of remote code execution as root, with no user interaction ("zero-click"), against a server with an active Multipath TCP (MPTCP) listener, exploiting this same race condition. According to the report, the exploit's first stage leaked a kernel pointer and defeated KASLR (kernel address space layout randomization) in approximately 48 minutes; the second stage turned the memory corruption into control-flow hijacking and ran an attacker-chosen command as root in about five additional minutes.

A technical detail helps explain why the race is practical: a failed attempt can leave the handshake incomplete without necessarily crashing the host, which allows the attempt to be repeated multiple times without raising obvious suspicion. MPTCP, officially documented by the Linux kernel itself, extends standard TCP to let a connection use multiple network subflows while maintaining compatibility with existing applications, and many distributions already ship MPTCP support enabled even when the application doesn't explicitly request it.

It's important not to stretch this proof beyond what it shows. The research material itself doesn't establish a success rate at scale, nor that the same exploit works unmodified across different kernel builds, CPU architectures, memory allocators, and hardening profiles. The defensible claim is: the flaw is remotely reachable over the network, Anthropic demonstrated unauthenticated code execution as root against a vulnerable MPTCP listener in a controlled environment, and broader exploitation depends on the target.

Why the CNA, Red Hat, and Ubuntu disagree on the score

The 9.8 score in the Linux CNA record describes the upstream component in the worst plausible scenario. Specific distributions assess the same defect against the code they actually package, with their own configurations and mitigations. Ubuntu, for instance, keeps the 9.8 CVSS 3.1 score on its public page, but also publishes a CVSS 4.0 score of 8.3 with attack requirements present, reflecting preconditions that the older vector didn't capture well.

For RHEL environments, the practical guidance is to check Red Hat's active advisory rather than applying a generic upstream score to every distributed product. The AlmaLinux case illustrates the opposite problem: as of the October 30, 2026 snapshot used as the basis for this report, there was no independent confirmation via a distribution-specific official advisory for this CVE, which should not be read as proof that the system is secure.

How to check whether your server is exposed

The practical response recommended by the research follows a straightforward sequence:

1. Map which Linux TCP services are reachable over the network, including Kubernetes nodes, reverse proxies, and appliances that use the Linux networking stack.
2. Identify exactly which vendor kernel is running, without assuming that uname -r alone settles the question: enterprise distributions often backport fixes while keeping an older-looking base version.
3. Install the fixed build provided by the vendor and reboot for it to take effect.
4. Keep evidence (package changelog, build metadata, or a VEX statement) that the running kernel contains the fix.
5. Give immediate attention to hosts with an MPTCP listener, because that's exactly the configuration public research validated as a path to remote root.

Teams running Go services also need specific attention: an advisory from the Go Security Team, archived on October 30, 2026 (original announcement sent October 29, Pacific time), warns that Go programs on Linux can expose MPTCP listeners even when whoever operated the service didn't deliberately choose to do so. The recommendation is to fix the kernel rather than trying to disable MPTCP program by program, an approach described as fragile and liable to leave another listener exposed.

What still isn't proven

None of the sources cited here establish mass exploitation across the public internet. A high volume of retransmitted SYNs is not, by itself, evidence of exploitation: packet loss, asymmetric routing, service overload, and middleboxes already produce this pattern normally, and correlating it with real signs of use-after-free requires more than a network alert. Disabling MPTCP reduces immediate exposure to the specific path used in the research, but it doesn't remove the memory lifecycle defect in standard IPv4; the lasting fix remains the kernel patch.