TCP Use-After-Free: CVE-2026-98432 / CVSS 9.8

Original Article ↗ Hacker News Discussion ↗

A severe Linux kernel vulnerability (CVE-2026-98432, CVSS 9.8) in the IPv4 TCP stack allows a use-after-free during the TCP handshake, which Anthropic demonstrated can be turned into a remote root exploit, especially on systems with multipath TCP (MPTCP) listeners. Commenters focus on practical impact and mitigations: many distributions and OpenWrt are still rolling out fixed kernels, MPTCP can often be disabled, and dropping IPv4 packets with IP options at the firewall or via XDP is suggested as a partial safeguard, though not a complete fix. There is broad concern about unpatched routers and IoT devices, debate over how quickly vendors like Ubuntu and RHEL should respond, and reflection on how AI-driven vulnerability discovery and memory-unsafe C code in critical subsystems are reshaping the security landscape.

Scope and nature of the vulnerability

  • Use-after-free in Linux IPv4 TCP handling during the handshake, in code run before traffic reaches applications.
  • A successful exploit can achieve remote code execution as root on affected kernels.
  • IPv6 path is reported as unaffected; issue is tied to IPv4 options handling.
  • Exploit is easier on multi-core systems; single-core or single-queue setups may be effectively safe.

Role of Multipath TCP (MPTCP)

  • Disagreement in thread:
    • One line of discussion: exploitability demonstrated via MPTCP listeners (e.g., Go 1.24 enabling MPTCP by default, some servers like Caddy/Tailscale using it).
    • Others emphasize the bug is in generic TCP code; MPTCP just made the proof-of-concept easier, and a non-MPTCP path might also be exploitable.
  • Clarification that MPTCP uses TCP options, while the bug is in IP options; some confusion here is explicitly called out.

Who is affected

  • All Linux kernels from 4.4 up to specific fixed releases (e.g., 5.15.225, 6.1.190, etc.) are said to be affected.
  • Major distros:
    • Debian has shipped fixes; Ubuntu and RHEL are criticized for lagging, though Ubuntu has kernels in “proposed” and RHEL ships with MPTCP disabled by default.
    • Proxmox reports having shipped patched kernels earlier via its own pipeline.
  • OpenWrt and other router distros often run vulnerable kernels, though WAN-facing services may be closed or firewalled by default.

Mitigations and practical exploitability

  • Common suggested mitigations:
    • Disable MPTCP (sysctl net.mptcp.enabled = 0, Go GODEBUG/go.mod flags).
    • Drop IPv4 packets with IP options at firewall level (iptables/nftables/ufw; XDP for higher assurance).
  • Some note that many ISP and enterprise routers already drop IP options; others argue this is not universal.
  • Reported lab exploit: ~48 minutes to leak a kernel pointer, plus ~5 minutes to gain shell.

Routers, IoT, and consumer gear

  • Concern that many embedded devices (routers, “smart” gadgets) run affected Linux versions but never get updates.
  • Partial comfort: some cheap IoT boxes may be single-core or old kernels; others point out multi-core consumer routers are now common.

Ecosystem and operational debate

  • Strong criticism of slow response from “enterprise” distros vs. praise for faster-moving projects.
  • Some admins shut down or aggressively locked down servers until patches land.
  • Discussion that constant severe CVEs + LLM-aided exploit discovery may force shorter patch cycles and better isolation (VMs, bastions, VLANs).

Languages, architecture, and AI

  • Renewed calls for more Rust and memory-safe networking stacks; counter-arguments that rewrites introduce new (non-memory) bugs and often still rely on unsafe.
  • Mention that parts of the Linux kernel are already being moved to Rust (e.g., specific drivers).
  • Mixed views on LLMs:
    • Seen as powerful tools for finding and weaponizing bugs.
    • Worry that AI will drive a sustained “CVE flood,” but also optimism that flushing out old bugs could make systems more secure long-term.

Attitudes and uncertainty

  • Some treat this as a near-emergency for public-facing Linux servers; others downplay it as hard to exploit across the wider internet and “nothingburger” once mitigations and load balancers are considered.
  • Several questions remain unclear in the thread, including exact exploitability behind various middleboxes and whether all suggested firewall rules fully mitigate non-MPTCP paths.