Linux TCP Use-After-Free: Patch vs Mitigate

Your kernel has a remotely reachable use-after-free in the TCP handshake path, your distro hasn't shipped a fix, and someone has already demonstrated a working root exploit. So what's the plan: sit tight and wait, or start dropping packets at the firewall? The Linux TCP use-after-free disclosed as CVE-2026-98432 is a clean case study in the oldest decision in security operations — patch versus mitigate — and the honest answer is that the two options are not symmetrical at all. One of them actually fixes the problem.

I've been on both sides of this call. I've held off on an emergency kernel rollout because the mitigation looked good enough on paper, and I've also watched a "temporary" firewall rule quietly rot in production for eight months while everyone forgot the CVE it was papering over. This bug is a good forcing function to talk through when each approach wins, because the trade-offs here are unusually legible.

What the TCP Use-After-Free Actually Is

The mechanics matter here because they determine what a mitigation can and cannot do. When your server accepts an IPv4 TCP connection, the kernel tracks the half-open handshake in a lightweight request socket, then promotes it to a full socket once the handshake completes. If the peer's IPv4 header carried options, the kernel saves them to echo in its replies. The bug: the kernel handed those saved options to the new connection without copying them, then freed them immediately — while another CPU could still be reading them to build a handshake reply. That's a use-after-free, reachable by a remote, unauthenticated peer, before a single line of your application code runs.

The upstream fix, from Eric Dumazet, is four lines: two plain kfree() calls become kfree_rcu(), which defers the free until every reader has finished with the memory. It's the canonical kernel fix for this exact class of bug — readers under RCU hold references you can't see, so you let the grace period expire before reclaiming. The kernel's own CNA scored it CVSS 9.8. Red Hat initially scored it 8.1, then raised it to 9.8 Critical on October 30, citing the lack of network prerequisites.

Two details change the exposure math. First, the race loses gracefully: a failed attempt just fails the handshake without panicking the box, so an attacker can retry indefinitely. Second, the exploit path Anthropic demonstrated targets hosts with a multipath TCP listener — and per the Go Security Team, Go programs have opened MPTCP listeners by default on Linux since Go 1.24, wherever the kernel permits it. Check your fleet:

ss -Mlnp                 # MPTCP listeners and their owning processes
sysctl net.mptcp.enabled # 1 means apps may open MPTCP sockets

An empty ss -M output means no MPTCP listener. But don't get comfortable — the Go team is explicit that the underlying bug isn't MPTCP-specific. It's a generic UAF in handshake processing; MPTCP is just the path someone has proven end-to-end.

The Patch Path: Fixed Kernel, Reboot, Done

Patching is boring to describe because it's the only option that eliminates the vulnerability rather than reshaping it. Fixed kernels shipped upstream on October 11 and 15 across every maintained stable line, and the bug stretches back to Linux 4.4 — which means a lot of long-tail systems are affected, including kernels old enough that upstream won't touch them.

The catch is the reboot. A kernel update does nothing until the machine boots into it, and rebooting is where the real operational cost lives: drained Kubernetes nodes, failover rehearsals, the database primary nobody wants to bounce during business hours. This is why "just patch" is always correct and never sufficient as advice. You need a rollout plan — canary hosts first, then stateless tiers, then the stateful ones with maintenance windows. If you've been through a fleet-wide emergency kernel rotation before, you already know the drill. The teams that handle these well are the ones who rehearsed node draining when nothing was on fire; the defensive engineering habits you build on quiet Tuesdays are what pay out during a 9.8.

One trap worth naming: dpkg -l or rpm -q kernel showing a fixed package means nothing if the running kernel predates it. uname -r tells you what's actually executing. On RHEL-likes, needs-restarting -r will tell you plainly whether a reboot is pending. I've reviewed post-incident reports where the "patched" fleet was a fleet of installed-but-not-running kernels. Verify the running version against your distro's tracker, not the upstream number — distro kernels carry backports under their own versioning.

The Mitigation Path: Drop IPv4 Options, Disable MPTCP

The published interim mitigation is an nftables rule that drops incoming IPv4 TCP packets carrying IP options — the trigger condition for the vulnerable path. You can complement it by disabling MPTCP (sysctl -w net.mptcp.enabled=0) if you don't use it. Both are fast, rebootless, and deployable with configuration management in an afternoon. That's the appeal.

Now the part that should temper your enthusiasm: Red Hat's own bulletin says its rule "reduces exposure to this vulnerability but cannot fully prevent it." Read that sentence twice. The mitigation narrows the attack surface; it does not close it. Packets with IP options are rare in normal traffic — most middleboxes drop them anyway, which is one reason exploitation over the open internet is considered unlikely — but "rare" and "impossible" are different words, and the bug is in generic handshake code, not only in the options path someone happened to test.

There's also a subtler cost: mitigations create a false sense of closure. The ticket gets moved to "done-ish," the urgency drains out of the patching effort, and six weeks later you're still running a vulnerable kernel behind a packet filter, with institutional memory of why fading fast. I've written about this pattern before in the context of PHP's critical CVE window, where the teams that just pulled the vulnerable thing offline fared better than the ones who stacked clever filters. Same lesson, different stack.

Patch vs Mitigate: When Each One Wins

Here's my honest scorecard, after years of making this call under pressure.

• Fixed kernel is available for your distro. Patch wins outright. Debian, SUSE Enterprise, Oracle UEK, and Amazon Linux all shipped fixes. There is no mitigation cleverer than a four-line upstream fix. Schedule the reboots, roll in rings, move on.
• No fixed kernel yet, exposure is real. Mitigate immediately — this is exactly what mitigations are for. Ubuntu and RHEL were still "Vulnerable"/"affected" at the end of October. If you're internet-facing with an MPTCP listener, drop IP-options packets and disable MPTCP today, while tracking the fixed kernel like a release you're blocking on.
• Internet-facing but behind a managed front door. Your urgency drops. AWS's guidance — that traffic fronted by their load balancers, CloudFront, or API Gateway doesn't reach your instances as raw untrusted TCP — is sound. Mitigate anyway (it's cheap), patch within a normal cycle rather than an emergency one.
• Single-core or single-queue systems. Lower priority. The race needs concurrent packet processing on multiple CPUs. Embedded and tiny VMs get some breathing room — but they also tend to be the boxes nobody ever reboots, so don't let "low priority" become "never."
• End-of-life kernels (pre-5.10 upstream). Mitigation is your only upstream-independent option. This is the scenario where mitigations genuinely win, because the alternative is a vendor backport that may never come. It's also a loud signal that the box itself is the vulnerability, and the real fix is replacing it.

The Distro Gap Is the Real Story

The detail that should bother you isn't the bug — four-line UAF fixes land in stable kernels every month. It's that two of the biggest server distributions on Earth, Ubuntu and RHEL, were still without shipped fixes more than two weeks after upstream, while Amazon Linux had patched every one of its kernels and AlmaLinux, a community rebuild, had fixed kernels in testing ahead of its upstream. The HN commentariat noticed, and they're right to be annoyed: these are the distributions that market themselves hardest on server readiness.

For practitioners, the takeaway is unglamorous: your exposure window is defined by your vendor's backport pipeline, not by upstream. That argues for two things. First, know your distro's tracker URLs and actually watch them — this CVE sat at "Received" on NVD with no analysis while the kernel CNA, Red Hat, and the distros all had detailed pages up. Second, treat distro responsiveness as a selection criterion. Amazon Linux just demonstrated a meaningfully faster kernel-fix pipeline than the two incumbents. That won't matter in a marketing deck, but it matters on Halloween weekend when a 9.8 drops.

The AI-Written Exploit Changes the Clock

The most consequential line in the disclosure is easy to skim past: Anthropic reports that its Claude model produced a working remote-root exploit — after initial prompting, taking under an hour of machine time to go from kernel pointer leak to root shell. They haven't published it, and skeptics on HN had fun with the "trust me bro" framing. Fair. But even discounted for marketing, the direction is unmistakable: the time between "diff lands in the stable tree" and "working exploit exists" is collapsing, because the exploit-writing bottleneck was never the bug — it was the human who could read the diff and do the heap grooming.

That compresses the patch-versus-mitigate decision window. When exploit development took weeks, "mitigate now, patch next maintenance window" was defensible. When a model can grind out a PoC overnight from a public commit, your mitigation phase needs to be measured in hours, and your patching phase in days. The four-line fix is public. Anyone can study it. Assume the exploit is too.

My Recommendation

Patch. Mitigate only as a bridge, and put an expiry date on the bridge. Concretely: if your distro has a fixed kernel, start rolling it now and verify uname -r after every reboot. If you're on Ubuntu or RHEL, deploy the IP-options drop and disable MPTCP today, then treat the missing kernel fix as a blocking dependency — check the tracker daily, not weekly. Prioritize anything internet-facing with an MPTCP listener, then everything else that accepts inbound TCP, which is nearly everything. Containers don't save you; they share the host kernel, so patch the nodes.

The deeper lesson is the one this bug teaches every few years under a new CVE number: mitigations buy time, but only patches close holes, and the time mitigations buy is getting shorter. Build the muscle for fast, safe kernel rollouts before you need it — because the next four-line fix is already sitting in someone's queue.