This is why I don't take Ubuntu seriously. They just take whatever is the latest kernel when they release the next Ubuntu version regardless of whether it is a LTS kernel or not. Which means they often end up with an upstream EOL kernel they themselves have to backport patches to for years, which in turn lead to delays like this. It's not going to get any better going forward.

The article sounds a bit sloppy.
In general this is a pretty low risk exploit. Can be used for trolling, but not to steal data or get rce.

The freed memory can be read again as the child socket is constructed, which leads to a use‑after‑free that can trigger a kernel crash or a denial of service. The vulnerability does not directly leak data.

https://app.opencve.io/cve/CVE-2026-98432

The only mention I see of things beyond that are claims of rce on systems with multi-path tcp, which is rare.
This sounds like another overblown ai-company-discovered vulnerability. They have every reason to disclose poorly and create the biggest possible fear. Even the php exploit, which was a lot worse than this, still had way more publicity and fear than it deserved.

Context from the article for those that don’t like clicking ..

Debian patched it on October 16. Ubuntu still doesn't have a patch more than two weeks later. Every supported release, LTS included, is listed as "Vulnerable".

Ubuntu hasn't shipped the patch nine days after it was rated 9.8 and six days after a working root exploit.

That feeling when Debian is more up-to-date than you....

There's also no livepatches from Ubuntu Pro, and I thought this was the whole idea of livepatches, to patch critical bugs before you have a chance to update the kernel.

This also isn't the first time I've been annoyed at Ubuntu's response time. Luckily I mostly run Debian, but I certainly won't be using Ubuntu for anything else in the future.

canonical takes ages to ship patches sometimes, not just with security vulns. it's part of the reason i hopped away.

you do know you can just put a firewall rule in to prevent any IP options from hitting the server

The rule (matches header length > 20 bytes, i.e. IHL 6–15):

iptables -I INPUT 1 -m u32 --u32 "0>>24&0x0F=6:15" -m comment --comment ipopts-stopgap -j DROP

• ufw: add -A ufw-before-input -m u32 --u32 "0>>24&0x0F=6:15" -j DROP to /etc/ufw/before.rules, above the RELATED,ESTABLISHED accept line. Then run ufw reload.
• csf: put the iptables line in /usr/local/csf/bin/csfpre.sh so it survives csf restarts.
• Docker hosts: use -t raw -I PREROUTING instead, so container traffic is covered too.

Test: run ping -R at the box and watch the counter go up in iptables -L INPUT -v -n. Note that many networks drop option packets in transit, so test from the same LAN or a local netns.

its a stopgap. not a fix. but you don't have to take all your servers offline ..... just put the block in and wait for the patch

Apparently ubuntu is for the latest features, not the latest security fixes, for those you need debian to be updated at the highest pace

It's pretty bad...