"TCP stack" versus "Linux TCP stack" is an OOM in terms of relevance.

Dropping packets with IP options from XDP should be a more complete mitigation (also more performant).

> Exploitability over the internet is unlikely, most ISP routers drop packets with ipoptions fields.

That doesn't track. Apple iPhones are a major user of MPTCP and they report the majority of requests supporting MPTCP, IIRC 70+%.

And it takes around an hour to do this in lab setting locally:

> An enabling property of this race condition is that a lost race only fails the handshake without crashing the whole system, so a determined attacker can retry indefinitely until they succeed. In our proof of concept, it takes 48 minutes to leak a kernel pointer and another five minutes to reach the shell command execution

source: https://www.anthropic.com/research/discovering-vulnerabiliti...

https://pwn.watch/ has an RSS feed available

The openwall oss-security list usually covers a decent number of issues and this CVE was mentioned there yesterday:

https://www.openwall.com/lists/oss-security/

Any chance you’d mind sharing your list?

It's one of two things: Either they have found some regression with enterprise customers, or they are not happy with the fix.

RHEL runs with MP-TCP disabled by default, they initially listed it as Important only to later raise it to Critical.

If you read commit logs of, say kernel.org and a distro kernel, and aren't concerned you are blissfully ignorant (and it is worse for the broader userland repos). It's particularly bad when they don't track a kernel.org LTS. Their kernel orgs are pretty lean and this has been the status quo for decades. CVEs of sufficient stature like this will get fixed but majority of other issues slip by unnoticed. LTS is kind of a myth, it trades ABI and API stability for a lot of other issues.

Given the current and rapidly upcoming environment, would that not imply that those are no longer viable choices? As like a fairly urgent emergency consideration?

If they cannot demonstate being systematically able to adapt towards the required reaction time (minutes? hours?) by almost-comically many orders of magnitude (multiple weeks), and it is only going to get worse, then what other conclusion could there be?

Like they'll only organizationally adapt when it's far too late (everybody using their shit has already been pwned), and then it'll be an unpracticed emergency adaptation.

> How are Ubuntu and RHEL not fixed?

Ubuntu has had kernels in the "proposed" component for several days now if you want to pull it in manually. Not yet pushed to "security" or "updates".

It seems particularly crazy for Ubuntu given that Debian released their fix something like a couple weeks ago.

I’m pretty confused because apparently Anthropic is the group that followed “responsible disclosure” but apparently even though upstream was patched a couple weeks ago, still nothing on either.

>How are Ubuntu and RHEL not fixed?

IMNSHO this makes them unfit for purpose. I think this is the nail in the coffin for Ubuntu for me.

Going by the proxmox forum the fix is already in the sources (proxmox released their kernel based on them a few days ago). But I could not see, if it is already released for the users.

https://forum.proxmox.com/threads/cve-2026-98432-in-proxmox-...

Running regression tests I assume; they can't just YOLO shit like most OSS projects for the exact reason you mention.

The good news is, if you emergency patched your Debian for php2shell, you probably got the new kernel on the same apt run. This time the embargo actually held, and the new kernel was out before the CVE came public

Interestingly, Ubuntu Priority is set to "High" and not "Critical" which is defined as:

"A significant problem, typically exploitable for nearly all users in a default installation of Ubuntu. Includes serious remote denial of service, local root privilege escalations, local data theft, and data loss."

> https://ubuntu.com/security/CVE-2026-98432

The listed kernels are in the "proposed" component (and not yet in "security" or "udpates") if you want to pull them down onto canary systems for testing before going to production.

so just block multipath and add the firewall rule from article that drops packets with IPv4 options

I'm more worried about my consumer-grade router.

The timeline says the CVE was reported over 2 weeks ago, so why are the alarms sounding now?

Note: AWS NLB doesn't terminate TCP for TCP listeners.

It would be great if they introduced mitigations for this vulnerability though.

Another reason hyperscaler cloud providers will continue to grow (IMO)!

IoT devices will get fixes delivered on the 12th of never.

You should assume your IoT junk is already compromised, that's why your IoT junk runs on a dedicated VLAN.

With all the "Claude rewrote X in rust!" posts lately, I'm waiting on the inevitable Linux kernel rewrite post.

Vibe code aside I feel targeted rewrites are becoming more and more justified.

You would be surprised. A lot of cheap consumer routers are have two or four ARM cores. The bigger issue is that they are typically running a kernel from the stone age (< 6.0.0). Sometimes a still-supported LTS kernel like 5.10 or 5.15, but then they stopped at an old patch level.

Heck, apparently even the new Unifi UCG Fiber is running 5.4.213 (September 2022), but maybe they backport some fixes?

[1] https://community.ui.com/releases/dd0283dc-bf71-4140-ae1d-c1...

Those routers probably have 20 other critical un-patched exploits ...

An entire ecosystem of malware crawling and cohabiting in them.