Linux TCP use-after-free (CVE-2026-98432): patch now, hunt later

What happened

On October 30, a researcher operating under the handle `atlasum` published a writeup of CVE-2026-98432, a use-after-free in the Linux kernel's IPv4 TCP implementation. The scoring is the kind that makes on-call pagers vibrate off the desk: CVSS 9.8, network-reachable, no authentication, no user interaction, confidentiality/integrity/availability all `HIGH`. The affected code lives in `net/ipv4/tcp_input.c` and `net/ipv4/tcp_ipv4.c`, specifically in the interaction between `tcp_rcv_state_process()` and the socket destruction path invoked by `tcp_done()`.

The trigger is a race, not a single malformed packet: an attacker ships a crafted `SYN` → `SYN/ACK` → `ACK` → data → `RST` sequence timed to land while the kernel is still processing an in-flight `sk_buff` for the same four-tuple, which frees the socket out from under the receive path. The resulting dangling pointer gets dereferenced in softirq context, and because the freed object is a `struct sock` allocated out of a dedicated SLAB cache, heap grooming for a usable overlap is practical rather than theoretical. The disclosure includes a proof-of-concept that reliably panics an unpatched 6.6.73 kernel in under a second and a second PoC that leaks a kernel pointer via a side channel in the TCP timestamp option.

The fix shipped as a four-commit series from Eric Dumazet, merged into net-next on October 29 and backported the same day. Fixed kernels: 6.12.6, 6.11.11, 6.6.74, 6.1.129, 5.15.195, 5.10.249. Red Hat has assigned it RHSA-2026:7812 (RHEL 8/9), Ubuntu is tracking it as USN-7641-1, Debian as DSA-5820-1, and Amazon Linux as ALAS2023-2026-1061. SUSE's advisory is SUSE-SU-2026:3904-1. Google Container-Optimized OS pushed `cos-105-17412.370.0` within 36 hours. Android devices built against 5.10/5.15 Common Kernel branches will get the fix via the November 2026 ASB.

Why it matters

The depressing part is that this is almost exactly the shape of CVE-2024-36971 — another TCP teardown-path UAF Dumazet fixed last year — just in a different corner of the state machine. The IPv4 TCP code is one of the most audited pieces of software in human history, and it is still shipping remote use-after-frees against listening sockets in 2026. That's not a condemnation of the maintainers; it's a reminder that "old, boring code" is still *concurrent* code, and the SMP memory model under softirq is unforgiving.

The second thing worth noting is reachability. Unlike `nf_tables` or io_uring bugs — which require either a local foothold or an unusual sysctl — this one hits the default path that every Linux box with a TCP listener runs. If `ss -tln` shows anything on `0.0.0.0`, you are reachable. That includes your bastion hosts, your Postgres read replicas that "only accept connections from the VPC" (the VPC includes your compromised node), your Kubernetes API servers, every sidecar envoy, and the forgotten jumpbox from 2019 that still has a public ENI because nobody wants to be the one to delete it.

Third: the mitigation story is thin. There's no sysctl you can flip, no iptables rule that reliably blocks the race (the attack uses *valid* TCP packets, just timed adversarially). The only real mitigation is the patch — nftables rate-limiting on new connections *reduces* reliability but doesn't close the window, and anyone selling you a WAF signature for this is selling you theater. Dumazet's own commit message is characteristically dry: *"The window is small but reachable from untrusted peers. Backport advised."* When Eric says "backport advised," treat that as a P0.

The community reaction on the HN thread has split along predictable lines. One camp is doing the usual "this is why we need Rust in the kernel" victory lap, which — fine, maybe, but Rust-for-Linux isn't going to rewrite `tcp_input.c` any time this decade, and the specific bug class here (SMP teardown ordering) is not obviously prevented by the current `rustc` borrow checker without a lot of unsafe. The other camp is pointing out, correctly, that the real failure mode is patch latency, not language choice. Shodan is already showing ~14M internet-reachable SSH endpoints running kernels older than 6.6.74. Those boxes are going to stay vulnerable for months.

What this means for your stack

First, triage. Run `uname -r` on everything, cross-reference against the fixed-version list, and anything older than your distro's advisory kernel is a P0 reboot. `kexec` works if you really can't take a downtime window, but the UAF is in networking code — a live-patch via `kpatch`/`livepatch` is risky because you're modifying the exact subsystem under load. Reboot is cleaner.

For your cloud fleet: AWS has already rolled new AMIs for Amazon Linux 2023 and the Ubuntu Pro images — if you build on top of those with Packer/EC2 Image Builder, kick a rebuild and roll your ASGs. GKE and EKS node pools: upgrade to the November patch channel; both GCP and AWS have published node images with the fix. If you're on bare metal with Ubuntu, `unattended-upgrades` will pull `linux-image-generic` 6.8.0-52 or newer — but it will *not* reboot the host. Check `/var/run/reboot-required` and schedule it, or use `needrestart -r a` in a maintenance window.

The uglier population is embedded and appliance Linux. Anything running a vendor kernel — your firewalls, load balancers, SAN controllers, VPN concentrators, that one Supermicro BMC — is at the mercy of the vendor's release cadence, which historically is measured in quarters. For anything you can't patch this week, the only defense in depth that actually helps is network segmentation: drop inbound TCP from untrusted networks at a device that *is* patched. If your edge firewall is itself a Linux box, patch that first.

Finally, do the post-mortem exercise. Pull your TCP connection logs for the week ending today. Look for repeated short-lived connections from the same source hitting the same port with unusual RST timing — the PoC leaves a signature (a burst of 4-6 packets with specific window sizes) that's distinctive if you have the pcaps. Zeek's `conn.log` with `history` field containing `ShADafR` in under 100ms is a reasonable starting IoC. You probably won't find anything — the bug is a day old publicly — but the muscle memory of "we actually hunted" is the muscle you want trained before the next one.

Looking ahead

The right lesson from CVE-2026-98432 is not "TCP is broken" or "rewrite it in Rust" — it is that the window between public PoC and mass exploitation keeps shrinking, and the fleet-wide patch latency of the Linux ecosystem has not improved to match. The kernel maintainers did their part in under 48 hours. Whether your boxes are patched by this time next week is a question about your deployment pipeline, not about `net/ipv4/`. If the honest answer is "probably not," that's the finding worth taking to your next planning meeting — not this specific CVE, but the class of them, and the fact that there will be another one before Christmas.