However they also claim the mitigation "reduces exposure to this vulnerability but cannot fully prevent it", without elaborating on what that means or how it would be possible... I've also not seen anyone else make this claim.
I am hoping to see an indication that https://grsecurity.net/ patches preemptively mitigated CVE-2026-98432 but I'm feeling less optimistic.
This vulnerability has been a stark reminder to why in some places things are running on HardenedBSD instead of Linux.
Separate from any of those, a good chunk of America's more sensitive production database clusters, other workloads, and some network applications are scheduled by Nomad or Kubernetes running directly on a kernel that is not Linux.
The most popular kernel is not necessarily appropriate for all use cases or types of environments where high-value targets reside.
Directly downstream of FreeBSD, HardenedBSD achieved its long history of invulnerability to what were exploitable vulnerabilities in upstream through its advancements in the operating system layer.
https://hardenedbsd.org/content/easy-feature-comparison
> but security thru obscurity
Arrogance is stupidity.
In some advanced settings where tolerances for potential impacts resulting from exploited software vulnerabilities are intensely low, Kubernetes (userspace software) on HardenedBSD is choice for mission.
Like with the other two systems, those running Kubernetes userspace on them are self-sufficient and are not among the audience of external more general Kubernetes distro support channels.
If you happen to like RKE, check out https://Talos.dev which is the best Kubernetes on Linux distro (for most Kubernetes on Linux use cases).
_
@nijave
Nomad and Kubernetes schedule containers, which are rarely not Linux containers, yeah.
Both can schedule processes in FreeBSD's BSD Jails.
If someone wants to start an open Kubernetes on FreeBSD/HardenedBSD project I would encourage that. Personally I would like to see an open Kubernetes on illumos project.
As far as I know where Kubernetes on HardenedBSD runs is not interested in open projects.
Maybe you're thinking of jails? I'm not sure if there's any mainstream/popular distributed orchestration systems for those.
"Freenode" in 2026 is an entity actively hostile to open source software and while what they say here might be true, they are only saying it because it aligns with their biases. They are not a real news source.
My mitigation for this lack of patches has been using iptables.
iptables -A INPUT -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROPIt does not seem that complicated to patch, and kernel upgrades are a dime a dozen these days. So what is making them delay a fix for so long?
And do we feel about running no firewall?
For example Linux works totally fine without running dhcpcd and without running avahi. But on many systems where people think they run "no service", these two shall have ports open on your network and happily listening.
Sure, it's typically "only" on your LAN: but how long before we see exploits affecting even private LANs?
Tighten your stuff up guys.
I think you'll find that for most people, plugging the laptop in and having the network immediately available and automatically seeing their local printer is a pretty good reason.
> A zero-day (also known as a 0-day) is a vulnerability or security hole in a computer system unknown to its developers or anyone capable of mitigating it.
Apparently the meaning has evolved over the years.
So you make of that what you will, but in my experience it means the exploitation comes hand in hand with some far more esoteric chain that is not easy to put in practice.
How would you see one? Have you deployed your own army of honeypots that are actively logging and looking for corrupt IP options packets? If you're not already looking for it, I think it's very likely that most people who get hacked will have no way of knowing how it happened, so we can't consider those incidents as being a result of this particular bug.
Are you actually monitoring for this specifically or just trying to use a sample size of 1 group of servers to prove something?
Most of the October CVEs we've seen were situations that require an extremely complex chain of attacks - amazing if you want to break into a bank, or fuck up some grocery freezers, not so useful for scanning random public boxes and doing "hacks of opportunity"
Apologies for the lack of links - it's a scattering of random people I've read talking about this, not any coordinated study. But if you read between the lines on all of the threads about these CVEs, you'll notice a lack of "I was hit by this" stories - which is pretty normal for more complex vulnerabilities.
The reason these sat unnoticed for so long is precisely because it's difficult to actually exploit them.
If anyone has anecdotes to the contrary, I'm definitely interested in hearing it, of course!
Why does everything has to come with so much drama these days.
> 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 suppose locally-running malicious programs could send packets to the loopback address or one of its own IPs or something.
[1] https://access.redhat.com/security/vulnerabilities/RHSB-2026...
Every consumer router-wirelessAP I've seen runs linux.
I never see security upgrades for the kernels they use. Not one. Not ever.
Is this something that should be a cause for concern? Even if you don't run a consumer-grade tplink, netgear, asus, whatever router yourself.
Update: The context which I should have said is that I think LLMs are giving script kids nation state level tools and expertise. This known bug is always less interesting than the next twenty.
Most consumer routers run ancient stacks with all kinds of weird proprietary vendor patches that are tied to a specific kernel version. Looking at you Qualcomm!
However they generally also drop all traffic by default so from the WAN side they look like a black hole. I guess that's "safe" enough for most consumers.
For fun, take a look at the open PRs in the OpenWRT repos. Those people are doing some amazing work but it's also frustrating to see them struggle with things that _could_ be easy if the vendor made some slightly better choices.
I would strongly prefer something like OpenWRT though. Call me paranoid but after the last few weeks I'm increasingly less comfortable with connecting my devices to a blackbox.
There are plenty of out of support systems still in the wild and while I'm not arguing they are completely secure I was under the impression that kernel vulnerabilities generally make a minor exploit in something else worse (chained priv escalation for example) and generally are difficult to exploit on their own. If I'm mistaken I'd love to know
That includes the one port your LAMP stack uses.
Or, the attacker might be originating from the other side of a device, like within a LAN. Malicious employees/house guests/what-have-you could target devices from inside your network where most devices (not just servers) don't have as much protection and often have other open ports accessible, like file sharing/SMB, SSH, SMTP, RDP, databases etc.
How about forwarding a port for wireguard or ssh?
I'm thinking of what to do myself.
The ghost of android releasing 6 month old patches every month is going to come home to roost.
That would be a bold claim and one I've never heard before. Hard not to be suspicious of it.
This security flaw is unlikely to be the only security flaw that ever happens to a kernel used by routers.
The point: Consumer routers do not seem to get updates. Ever.
Is that a worry or what?
But what do I know about it beyond that?
But FWIW I run my AP in bridge mode. Wifi drivers and chip firmware seem to be riddled with exploits. I don't want my router & firewall on the same system as the AP.
at least with an open source os there are more paths forward.
Granted they are pro-sumer devices, not strictly consumer.
MIPS and Arm have no security issues ever so never need patching which is an x86 only thing? Or maybe this comment is no more relevant than pointing out not all Arm patches apply to x86?
LLMs are giving script kids nation state level tools and expertise.
full disclosure: they're my employer
unfortunately most lack SSH access or a real ability to test the kernel patch version.
Every consumer router-wirelessAP I've seen runs linux.
I never see security upgrades for the kernels they use. Not one. Not ever.
you can use proposed pocket as per this for latest LTS releases
Ubuntu was always the benefits of Debian without the inconvenient restrictions anyways, it wouldn't be surprising if their contradictive philosophy caused them to collapse by inability to eat the cake while having it simultaneously.
I've switched to Debian in professional servers around the time I learned how to use it without a Graphical Desktop Environments, that's roughly the stage at which a growing devleoper should drop the Ubuntu training wheels. Don't carry that into the workplace whenever possible.
sudo iptables -t raw -I PREROUTING -p tcp -m u32 ! --u32 "0>>24&0x0F=5" -j DROP
Ubuntu abandoned its way years ago, closing source, centralising features under Canonical umbrella., etc.
Seeing people complaining about Ubuntu tells me more about them than the company itself.