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

What it is

CVE-2026-98432 is a use-after-free in the Linux IPv4 TCP handshake. The page is a defender's guide, last checked 30 October 2026. It gives upstream stable fix versions, per-vendor verification steps, and read-only commands for inventory. The page was truncated before its mitigation section ended, so the FAQ and anything after it are missing.

How it works

During the handshake, tcp_v4_syn_recv_sock() moves the request socket's ireq_opt pointer to the child socket as inet_opt without copying it. A retransmitted SYN on another CPU can still read that object under RCU through tcp_v4_send_synack() and inet_csk_route_req(). The destructor frees it with plain kfree(), so the reader sees freed memory. A second path exists when net.ipv4.tcp_migrate_req=1 or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE program clones a request socket. The fix, commit e3f33b0a1d89, switches inet_sock_destruct() and tcp_v4_reqsk_destructor() to kfree_rcu().

The corresponding IPv6 function duplicates the options, so the main bug is IPv4-specific. The upstream text separately notes an IPv6 migration concern involving ipv6_opt with CALIPSO.

Preconditions / Affected

• The page names a CVSS 3.1 score of 9.8 from the Linux CNA (AV:N/AC:L/PR:N/UI:N). Ubuntu also publishes a CVSS 4.0 score of 8.3. Red Hat's score applies only to its own products and should be read from its live advisory.
• Anthropic's post of 27 October 2026 reports unauthenticated remote root command execution against an MPTCP listener in a lab. It took about 48 minutes to leak a kernel pointer and defeat KASLR, then about five minutes to reach command execution. Failed attempts need not crash the host. The page says this is not proof for ordinary TCP listeners.
• Go services can expose MPTCP without the operator choosing it. The Go Security Team notice says Go 1.24 defaults to multipathtcp=2. SetMultipathTCP overrides GODEBUG, so GODEBUG=multipathtcp=0 is not a fix.
• First upstream fixed releases: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 and 7.2.10. Do not use these for vendor kernels, because backports keep older version strings.
• Debian marks Bookworm 6.1.190-1 and Trixie 6.12.113-1 as fixed.
• As of 29 October, Ubuntu lists generic kernels for 26.10, 26.04, 24.04 and 22.04 as vulnerable with a fix in progress. Cloud, OEM and other flavors have separate rows.
• AlmaLinux status was not confirmed by an advisory, and the page says this is not evidence of safety.

What to do

Install the vendor-fixed kernel, reboot, and confirm the running kernel. Do this first on internet-facing hosts and MPTCP listeners. Containers share the host kernel, so node images need updating, including templates and golden images. Live patching counts only if the vendor ties it to this CVE.

Read-only inventory commands from the page:

uname -r
ss -Mani
ss -lntp
sysctl net.mptcp.enabled
ip mptcp endpoint show
ip mptcp limits show
sysctl net.ipv4.tcp_migrate_req

Run them in each network namespace. Proxmox hosts should also run pveversion -v, dpkg-query -W 'proxmox-kernel*' 'pve-kernel*' and proxmox-boot-tool kernel list. Check that the booted kernel is the updated one. RHEL-family hosts can use rpm -q kernel kernel-core.

If a reboot must wait, the page suggests these temporary measures: disable MPTCP if unused, restrict inbound TCP, remove unused listeners, and rate-limit upstream. It says none of these corrects the bug. It advises against sending exploit traffic to production.

Caveats

• Disabling MPTCP removes only the lab's exact listener configuration, not the IPv4 bug.
• Retransmitted SYNs occur naturally, so network alerts cannot confirm exploitation. Kernel stacks near ip_options_build() or ip_build_and_send_pkt() are stronger signals.
• The page gives no data on how many hosts are exposed or on in-the-wild exploitation.
• A host that shows signs of compromise should be rebuilt from a trusted image, not just patched.