Glonce

Linux kernel CVE-2026-98432: TCP use-after-free rated 9.8 upstream, 5.9 by Red Hat

securityThe Glonce editorsHacker News🔥63Glonce rating63Impact55Novelty60Relevance75Surprise55Players35Credibility80
Linux kernel CVE-2026-98432: TCP use-after-free rated 9.8 upstream, 5.9 by Red Hat

CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP handshake path, analysed in a write-up from Penligent. Two processors act on related request and child sockets that can both still reference the same IP options object. One path may free the object immediately, while another path, protected only as an RCU reader, keeps using it. The result is a stale kernel pointer in code reachable through network traffic.

The article's main point is that three different statements about severity should be read as complementary, not as rivals. The CVE record carries a CVSS 3.1 score of 9.8, the network-reachable, unauthenticated worst case with high confidentiality, integrity and availability impact. Red Hat's product analysis assigns a lower 5.9, because it treats exploitation as a difficult race and assesses the practical consequence in its supported products more conservatively. Separately, Anthropic's Frontier Red Team reported a working remote root code-execution chain against a Linux server with a Multipath TCP (MPTCP) listener in a controlled lab. The article calls that serious evidence of exploitability under a specific configuration, and not evidence that every unpatched Linux server, every ordinary TCP listener or every distribution build can be compromised the same way.

The mechanism, as the article describes it from the upstream CVE text and patch: during the server side of a TCP handshake the kernel keeps a lightweight request socket. When the handshake progresses, tcp_v4_syn_recv_sock() hands the request's ireq_opt pointer to the new child socket as inet_opt, without duplicating the object. Meanwhile another CPU can process a retransmitted SYN for the same request and send another SYN-ACK through tcp_check_req(). Functions such as tcp_v4_send_synack() and inet_csk_route_req() read the request's IP options inside an RCU read-side critical section, and later helpers such as ip_build_and_send_pkt() and ip_options_build() dereference fields of the options object. The reader assumes RCU protects the object, but the destructor frees it with ordinary kfree(), which does not wait for existing RCU readers. If the child socket is destroyed while the retransmitted-SYN path is still using the options, that second CPU reads memory that has returned to the allocator.

The primary upstream fix replaces immediate freeing with kfree_rcu() in the relevant destructors, so reclamation waits for an RCU grace period. It was merged as commit e3f33b0a1d89, titled "ipv4: free inet_opt and ireq_opt after an RCU grace period." The patch does not serialise operations behind a global lock, which would hurt scalability in a hot network path; it aligns reclamation with the synchronisation model the readers already use.

There is also a request-migration variant. If net.ipv4.tcp_migrate_req=1 is enabled, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program controls migration, the kernel may clone a request socket, and the old request and its clone can briefly share one options object. A CPU holding the old request can still use it while the clone is freed. For that reason the fix changes both inet_sock_destruct() and tcp_v4_reqsk_destructor() to use RCU-aware reclamation.

On IPv6, the article says the first bug is specific to the IPv4 child-socket path, because the corresponding IPv6 function duplicates options instead of transferring the pointer. But "IPv6 is unaffected" is too broad: the upstream text notes an IPv6 request-migration concern involving ipv6_opt when CALIPSO is present, handled separately.

The article lists what is not established. No authoritative source cited establishes widespread exploitation across the public internet. Anthropic's result is stronger than a crash-only proof and should influence urgency, but it gives no measured prevalence of vulnerable MPTCP services, no universal success rate, and no proof that the chain works unchanged across kernel builds, CPU architectures, allocators, hardening profiles and network paths. A high volume of SYN retransmissions is not evidence of exploitation: retransmits occur naturally from packet loss, asymmetric routing, overloaded services, client retries and middleboxes. A network alert can prioritise investigation but cannot prove a use-after-free occurred inside the kernel.

Version checks are another trap. No single upstream version string labels every vendor kernel, since enterprise distributions backport fixes while keeping an older-looking base version, and cloud and appliance vendors ship their own builds. A scanner that compares only uname -r against an upstream list can produce false positives and false negatives. The Debian security tracker maps the issue to fixed Debian kernel packages, and the Ubuntu CVE page tracks many Ubuntu kernel flavours independently. Trustworthy status comes from a vendor advisory, package changelog, build metadata, VEX statement or confirmation that the fix commit was backported.

The recommended response: identify reachable Linux TCP services, determine which vendor kernel is actually running, install the vendor-provided fixed build, reboot into it, and retain evidence that the running kernel contains the correction. Hosts exposing MPTCP listeners deserve immediate attention because the public research validated that environment. Internet-facing gateways, load balancers, Kubernetes nodes, VPN endpoints, reverse proxies and appliances using Linux networking deserve a fast inventory even without intentional MPTCP. Disabling MPTCP does not remove the underlying IPv4 lifetime bug; it removes the listener configuration used in the public research chain and can reduce immediate exposure where MPTCP is unnecessary. Patch deployment remains the durable correction.

Key facts

  • CVE-2026-98432 is a use-after-free in the Linux kernel's IPv4 TCP handshake path: the child socket's destructor frees shared IP options with plain kfree() while a retransmitted-SYN path on another CPU still reads them under RCU.
  • The CVE record carries CVSS 3.1 9.8; Red Hat's product analysis assigns 5.9 because it treats exploitation as a difficult race.
  • Anthropic's Frontier Red Team reported a working remote root code-execution chain against a Linux server with an MPTCP listener in a controlled lab.
  • The upstream fix, commit e3f33b0a1d89, switches to kfree_rcu() so memory is reclaimed only after an RCU grace period; a request-migration variant (tcp_migrate_req=1 or a BPF migrate program) is covered too.
  • Recommended response: use the vendor-fixed kernel build, reboot into it and keep evidence; disabling MPTCP reduces exposure but does not remove the bug.

Why it matters

A memory-lifetime bug in the kernel's TCP handshake is reachable through network traffic, and one party has shown a remote root code-execution chain in a lab. That makes it more than a crash bug. What makes the story useful is the spread of scores: 9.8 on the CVE record against 5.9 at Red Hat, with the Anthropic lab result as a third data point. The article argues that each describes something different: the upstream record gives the theoretical maximum impact, a distribution score describes the vendor's shipped code and configuration, and a research exploit shows one concrete path against one target. None should be discarded and none stretched beyond its scope.

Who it affects

Anyone running Linux servers that accept TCP connections. The article says hosts exposing MPTCP listeners deserve immediate attention because the public research validated that environment. Internet-facing gateways, load balancers, Kubernetes nodes, VPN endpoints, reverse proxies and appliances that use Linux networking should be inventoried quickly even if they do not intentionally enable MPTCP. Systems using net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program are exposed to the request-migration variant. Debian and Ubuntu users can consult their distributions' tracker pages for fixed packages.

How to use it

The article's sequence: identify reachable Linux TCP services; determine which vendor kernel is actually running; install the vendor-provided fixed build; reboot into it; and retain evidence that the running kernel contains the correction. For status, rely on a vendor advisory, package changelog, build metadata, VEX statement or confirmation of the backported fix commit (e3f33b0a1d89 upstream), not on comparing uname -r with an upstream release list. Where MPTCP is unnecessary, disabling it can meaningfully reduce immediate exposure, but it is a stopgap and not a substitute for patching.

How solid is it

The technical description comes from the Linux kernel CVE process and the upstream patch, as relayed by the article, and the Debian and Ubuntu trackers are cited as matching it. The Anthropic result is reported, not detailed: the article does not describe how the exploit chain works or how reliable it is. The article itself is a third-party write-up from Penligent, and the practical guidance is the author's judgement. No authoritative source cited establishes widespread exploitation across the public internet.

Risks and caveats

Do not read the lab result as proof that every unpatched server is trivially compromised: the article notes there is no measured prevalence of vulnerable MPTCP services, no universal success rate, and no proof the chain works unchanged across kernel builds, architectures, allocators and hardening profiles. Equally, a lower vendor score is not a reason to skip patching. Scanners that match only uname -r against upstream versions can mislead in both directions because vendors backport fixes. Spikes in SYN retransmissions are not by themselves evidence of exploitation; a network alert can prioritise investigation but cannot prove a use-after-free occurred. Saying "IPv6 is unaffected" is too broad, given the separately handled ipv6_opt and CALIPSO request-migration concern.

“ipv4: free inet_opt and ireq_opt after an RCU grace period.”

— Title of the upstream patch commit e3f33b0a1d89, as cited by Penligent