november 2026 · 5 min

Your Patch Clock Started at the Commit

Most teams start counting patch time when their distro publishes an advisory. That's the wrong clock. It starts when the fix is public, because a public fix tells anyone who's reading where the bug is.

CVE-2026-98432 is a use-after-free in Linux IPv4 TCP: the kernel frees a connection's IP options without waiting for an RCU grace period, and a concurrent SYN-ACK can read the freed memory. The fix landed upstream on October 5, ten days before the CVE, under a title that says exactly what changed: "ipv4: free inet_opt and ireq_opt after an RCU grace period".

That was 29 days ago. Here's the state of things today:

Nobody here is being careless. Backporting a TCP change across a decade of kernels is real work, and a bad kernel is its own outage. But your vendor's QA time is exposure you carry, so you need a plan for it.

What a Public Fix Is Worth Now

Anthropic says an unreleased internal model wrote a remote root exploit for this bug against servers with a multipath TCP listener. In its proof of concept, "it takes 48 minutes to leak a kernel pointer", then about five more to reach command execution, and "a lost race only fails the handshake without crashing the whole system", so it gets to keep trying. The code isn't public and, as of TuxCare's write-up on October 30, nobody had reproduced it independently. So this is one vendor's number.

Severity is argued too: the kernel CVE team and Ubuntu say 9.8, while TuxCare reports several vendors at 8.1. And Cyber Security News reports, citing Marcus Hutchins, what looks like internet-wide MPTCP scanning since November 2, with about 2.1 million servers reachable over MPTCP on 443. That's secondhand, and reachable doesn't mean unpatched.

My bet: going from a public fix to a working exploit is becoming the cheap part. Attackers get strong models with no limits, and they have the commit. Defenders get a change window.

The Mitigation Everyone Reaches For

The MPTCP detail makes this look like a niche bug, and it makes one sysctl look like the fix.

Red Hat's bulletin scopes it to "any system running a vulnerable kernel version with IPv4 TCP networking enabled". MPTCP is the setup Anthropic demonstrated; nobody has publicly shown an exploit without it, and nobody has ruled one out. AWS lists net.mptcp.enabled=0 as a step that "does not resolve the issue".

You may also have MPTCP without having chosen it. Go's GODEBUG docs say that since Go 1.24, multipathtcp defaults to listeners on. Any Go service built with a go 1.24 or later go.mod asks the kernel for it, unless it sets GODEBUG=multipathtcp=0. So look at what's actually listening:

ss -lnM

That lists MPTCP listeners only. Run it per network namespace, because the sysctl is per namespace too, and containers don't inherit your answer. Then notice the trap: flipping the sysctl doesn't touch a listener that's already running. It keeps MPTCP until the process restarts.

What Ubuntu and Red Hat publish is a packet filter that drops IPv4 TCP packets carrying IP options:

sudo nft -f - <<'EOF'
table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}
EOF

Ordinary web, mail and SSH traffic doesn't carry IP options, which is why this is cheap to try. Remove it with sudo nft delete table inet cve_2026_98432 once you're on a fixed kernel.

The Tradeoff

The filter reduces the risk and doesn't eliminate it. Ubuntu and Red Hat both say so, and Red Hat says patching is the only complete fix. It breaks anything that relies on IP options, and Ubuntu notes containers with their own networking need their own rule.

Acting on the commit date also costs you something. You ship mitigations for bugs that may turn out to be unexploitable, and sometimes you take a kernel before your vendor has soaked it. If you can't roll a kernel back quickly, don't start there. Start with the filter and the inventory.

But track the right number. For each critical fix: the date it was public upstream, the date your fleet was protected, and what covered the gap. Right now the risk is amplified, because finding and weaponizing bugs is getting cheaper faster than patching is. A dashboard that starts counting at the advisory is missing the first 29 days of this one.

← all posts