sudo iptables -t raw -I PREROUTING -p tcp -m u32 ! --u32 "0>>24&0x0F=5" -j DROP
Except in this case they have not issued any fix, for several weeks, to an extremely critical issue that most other distros have already patched for some time now.
For many this now means their trust is broken.
How much do you pay for this?
Which is the price Canonical chooses to charge, like they could charge money for this and they don't because they'd rather eat the loss for personal users for the advertising capability.
Why tf do we have options in the header at all if you ca drop everything that does, be secure and everything still works?
Why the actual F%$K haven't they been deprecated and packets using them dropped by literally every tcp/ip stack if their only function is to get you f%$king pwned?
That might be a very dumb question for all I know. Maybe i shouldn't be cranky. It all seems like there are some very blase attitudes to this kind of thing, that should not even exist anymore, creating massive security holes, with zero upside tradeoff.
The seeming asymmetry offends me.
On the one hand it increases the attack surface and so the security risk. On the other, nothing. Yeah, let's take /that/ tradeoff on behalf of the entire internet.
So I'm so stupid & ignorant of security I think I would define "Internet tcp/ip" which conformant stacks block this rubbish by default like they do any other non-conforming packet. Thus reducing the attack surface essentially with no tradeoff. Weird uses can use customised lwip or whatever for these uses where we don't know the who, the what or the why (or perhaps even the IF).
Seems like nobody is shipping these firewall rules by default on internet routers. We get the vulnerability and as a tradeoff we get nothing of any value to us. Who do we thank for that?
What is the rationale, the justification for not paring away the garbage that does nothing but create vulnerabilities?
Obvious and sensible engineering at a protocol level seems very worthwhile to me.
Red Hat also claims that netfilter is not enough: https://access.redhat.com/security/vulnerabilities/RHSB-2026...
> The following nftables table drops incoming IPv4 TCP packets that contain IP options, which reduces exposure to this vulnerability but cannot fully prevent it.
I know things like eBPF can technically bypass netfilter if someone tries hard enough, but I'm not sure if they're referring to any other ways to exploit this that a netfilter rule can't catch.
Firejail by default also allows unprivileged users to completely bypass any netfilter rules from the main network namespace... so if the user has that installed (even if they don't use it), it's something to keep in mind.
A system running multiple network namespaces might not have the same mitigations applied inside all of them, so be sure to check all of those, except there's no great way of even finding all the different namespaces running on a Linux system for some reason (please prove me wrong if something exists! lsns is not enough).
But yes I agree it seems strange that most posts/articles/etc. are not prominently giving out mitigation strategies.
Probably because most linux workloads these days run on containers where the orchestrator dynamically create some firewall rules and where these vuln could be used to jump from on compromised container to another or the host. In these case it is rather complicated to instruct all your users on how to implement these mitigations depending on the orchestrator, firewall used, etc. Much easier to patch.
But that requires kernel.unprivileged_userns_clone=1 as well as manually setting up ipvlan interfaces and new IP address/routing table, whereas firejail is SUID root and makes the same operation trivially easy.
Do note that eBPF can still bypass netfilter entirely, as can containers, or any process using a separate network namespace.
I don't get this vulnerability, it's been out there for weeks, completely public, yet it has stayed extremely opaque. Usually, the day a high profile vulnerability is made public, there's all kinds of guidance out there explaining exactly who it affects how, and there are day 0 patches. This one I still don't know whether is an RCE or DoS in practice! I don't know whether a computer blocking connections via a "normal firewall" protects me or not! It's incredibly frustrating.
https://almalinux.org/blog/2026-10-30-cve-2026-98432/#tempor...
> This one I still don't know whether is an RCE or DoS in practice!
It is. It depends on dumping (potentially) a lot of traffic at you to "luck" into the cpu core scheduler but obviously computers can increase their luck by doing something a lot. The RCE is real, the risk is probably lower if you're not high profile simply because it requires some about of CPU spend on the attackers side, not something that you just fire off at anything that will respond to a ping or `GET /config.php`.
> I don't know whether a computer blocking connections via a "normal firewall" protects me or not! It's incredibly frustrating.
It doesn't. Apply the above rules until your kernel is updated.
Hard disagree... the packet could be part of an existing TCP stream and get processed by nf_conntrack before it hits the filter.INPUT chain. Or a local application could be sending packets to the loopback interface that bypasses the input chain in various ways.
A custom netfilter rule may already exist that accepts the packet before your mitigation does. And nftables allows custom chains that run at a higher priority than filter.INPUT and could be accepted before it touches it.
This is why vendors are suggesting to use the raw.PREROUTING chain instead.
And what I said before about eBPF still stands... someone has written a mitigation that uses that instead since it runs even before PREROUTING: https://github.com/sevaepsteyn/cve-2026-98432-ebpf
And again, any processes that are part of a separate network namespace will not have the same netfilter rules applied that one has added within the main namespace.
Local processes / users can also easily bypass netfilter entirely by way of creating their own network namespaces via unshare/firejail/etc regardless of whether user namespaces are enabled.
> On installation, ufw is disabled with a default incoming policy of deny, a default forward policy of deny, and a default outgoing policy of allow, with stateful tracking for NEW connections for incoming and forwarded connections.
https://manpages.ubuntu.com/manpages/noble/man8/ufw.8.html
The more specific rule is probably more useful if you do intend to expose a TCP port though.
> tcp_v6_reqsk_destructor() has the same migration issue with ipv6_opt, which is only set by CALIPSO. This will be addressed in a separate patch.