ranger_danger
Disagree, I think it's still a good idea to try to mitigate e.g. root escalations via this bug from devices within your network as well, as they could become compromised at any moment via other means and then promote themselves to root.
Do note that eBPF can still bypass netfilter entirely, as can containers, or any process using a separate network namespace.
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.
A system running multiple network namespaces might also not have the same mitigations applied inside all of them.
But yes I agree it seems strange that most posts/articles/etc. are not prominently giving out mitigation strategies.
They may regret it when the battery dies and it's a $20k repair because they're actually structural components on those cars. Or a single $20 sensor dies that's part of a larger non-serviceable $5k component.
Consumers want protection from cars they can't afford to fix.
Insurance companies want protection from costly warranty repairs.
Mechanics want protection from cheap highly-integrated gatekept parts that they can't work on, and/or won't get paid as much for.
TL;DR They severely reduced the number of components by integrating parts into larger pieces. This trades upfront cost savings for longevity concerns and repair prices down the road.
One could argue the US wants to ban them solely because it undercuts other manufacturers, but there's more.
You can also argue it's not good for many other people, like:
- the average consumer (that expects a quality long-lasting product)
- the insurance companies that will be footing a lot of the repair bills
- independent repair shops that either won't get those jobs, cannot actually perform the work due to tech/service monopolies, or simply lose revenue because the work is shorter
Yes they have, and the article links directly to where they say so: https://ubuntu.com/security/CVE-2026-98432
I think the author probably assumes that after almost 3 weeks of the entire world going ape-shit over this, most people reading their post probably know about it already, or know how to find out more, so they didn't feel the need to elaborate.
> Why wait for Ubuntu at all?
There are many reasons... businesses often cannot go this route. But I don't see why it matters unless you're just trying to attack and discredit this person because you disagree with how they write their articles.
Why are you trying to farm out so much critical thinking to other people for you? It is easy to do a quick web search and find out everything one needs to know.
It's so much worse than this, and there is a staggering amount of misinformation running rampant about this bug.
MPTCP is not a requirement, it can be exploited merely by sending specially crafted TCP packets with (any) IP options set. No special MPTCP support, web servers or any specific software listeners are even necessary at all to trigger it, just send the packets and boom.
I think the reason people assume MPTCP is a requirement is because that's what the PoC used... but MPTCP itself also doesn't even rely solely on IP options.
Ubuntu also does not even list a single mitigation strategy... at least RHEL did.
And like I said, any normal TCP packet that contains IP (not TCP) options can trigger the bug. I cannot emphasize enough how important and absolutely ridiculous this is.
Like the post says, this is big enough to get a massive amount of people to completely stop trusting Ubuntu entirely and jump ship.
It's not even a contest anymore, that man is the heavyweight champ of air-gap security.
And the while loop shouldn't even run at all since front() never equals ' '.
12 != 8
I don't get it...
> As you can guess, this is an example of undefined behavior causing unintuitive results.
No I couldn't... and what undefined behavior where? They don't explain anything.
Someone (or their botnet) sending a "real" DDoS of a few terabits/sec of layer3 traffic your way cannot be stopped by software running at a higher layer at all. Your only recourse there is playing a cat-and-mouse game of who can change IP addresses fast enough.
But in fact they did elaborate, even before the news stories broke:
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c10
And again with the follow-up issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c10
And again with the follow-up issue: