Linux patches TCP use-after-free CVE-2026-98432; severity disputed
A race in the Linux kernel's IPv4 TCP connection setup (CVE-2026-98432) can corrupt kernel memory. Fixed upstream; distro patches lag and vendors disagree on severity.
A use-after-free in the Linux kernel's IPv4 TCP connection-setup path — CVE-2026-98432 — can leak or corrupt kernel memory on a host that accepts TCP connections. The upstream fix landed 5 October; the CVE published 15 October. There is no in-the-wild exploitation yet, but the severity is a mess: the kernel's own CVE team scores it 9.8, several distributions score it 8.1, and one Red Hat page says 5.9. If you run internet-facing TCP services on older kernels, track your distro's fix state rather than the headline number.
What the bug does
When a connection completes, tcp_v4_syn_recv_sock() hands the pending request's IP options (ireq->ireq_opt) to the new child socket without copying them. If that socket is torn down while another CPU is still reading those options to build a SYN-ACK for a retransmitted request, the kernel reads freed memory. The bug was introduced in Linux 4.4. The IPv6 path is not affected.
Severity is disputed
This is the part worth your attention. The kernel CVE team scored it 9.8 (attack complexity low), added to the record on 24 October; NVD carried that 9.8 without its own analysis as of 28 October. Red Hat's advisory, updated 29 October, rates it Important, 8.1; Oracle and SUSE also score 8.1; Amazon scores 7.0; and Red Hat's separate CVE page calls it Moderate, 5.9. The entire disagreement is attack complexity — the kernel team calls it low, the vendors call it high because the race is hard to win.
The trigger, per the kernel team: send a TCP connection request carrying IPv4 Record Route or Timestamp options, then resend it to race the teardown. Outcomes range from leaking adjacent kernel memory to memory corruption or a crash.
Patch status (as of 29 October)
Upstream fixed versions are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 and 7.3. Distributions lag unevenly:
- Shipped: Debian trixie and bookworm (16–22 Oct), Oracle Linux UEK (16 Oct), Amazon Linux 2023 (24/29 Oct), SUSE Linux Micro / openSUSE Leap 16.0.
- Not yet: Ubuntu 22.04–26.10 list the fix as work-in-progress; older Ubuntu LTS (16.04–20.04) are vulnerable with no fix. Red Hat has deferred RHEL 8/9/10 and OpenShift 4 (RHEL 7 is not affected). SLES 15/16 are in testing.
Red Hat says no available mitigation meets its standards.
Action checklist
- Inventory kernel versions and build dates across the fleet; anything on a distro kernel without the fix above is exposed.
- Apply the distro update where it has shipped (Debian, Oracle UEK, Amazon Linux 2023, SUSE). Match your train to the versions above.
- Where no fix exists yet (Ubuntu LTS, RHEL), prioritize hosts that terminate untrusted TCP — internet-facing listeners are the realistic attack surface.
- There is no vendor-blessed mitigation, so reducing exposure of raw TCP services to the internet is the interim lever.
- Watch for unexplained kernel panics on exposed hosts as a crude signal.
Exploitation status
No in-the-wild exploitation is reported as of 29 October in vendor advisories, the CVE record, or public trackers, and the flaw is not in the CISA KEV catalog. No public proof-of-concept has been released.
Reading the tea leaves
The bug was reported by Anthropic researcher Xinyang Ge — credited in the kernel fix — and Anthropic, per reporting at The Hacker News, says it built a working exploit against a multipath-TCP (MPTCP) listener that defeated KASLR and reached code execution as root, with the exploit written largely by one of its models. The exploit code is unpublished. Treat the specifics with caution: as The Hacker News itself notes, neither the CVE record nor the kernel fix mentions MPTCP, so that path rests on Anthropic's account alone. This lands the same week we covered Anthropic's claim that an internal model chained exploits across Chrome and kernels and Project Zero's Fuzzilli-vs-BigSleep comparison on V8. AI-assisted bug-finding is producing real, patched CVEs — and the job of verifying the vendor's framing is landing on everyone downstream.