I was previously Ubuntu-by-default for my random Linux boxen, but going to upgrade things and finding that Ubuntu didn't have a patch has shaken my faith in it. I probably won't choose it for new servers in the future.
It's rather uninteresting to note, once again, that Ubuntu has decided to do this. I would like to know the (official, if any - unofficial/speculative otherwise) reason WHY they have not.
It 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?
Is it a cause of concern? Yes. Will you get hacked? Most likely not.
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.
I know the context here is consumer routers, but for those reading who might be running a server, or a homelab, or anything that does accept connections from outside, I want to make it clear that "most likely not" turns into "likely trivial if targeted" for servers.
Can you give examples of kernel bugs that can be targeted on an otherwise locked down system? Let's say something running just LAMP and all other ports closed off with a software firewall. Even the one in this article seems very tricky to actually exploit.
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
Any TCP packet (with IP options) you can send to a Linux kernel that doesn't get DROP'd by netfilter makes you technically vulnerable.
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 servers don't have as much protection or have other open ports accessible.
This is one of the biggest benefits of using OpenWRT. They update the entire stack like every other month or so you’re never on an ancient kernel or utils.
Google Wifi used to be good about that. I even got a notification for when my AP was being EOL'd and would no longer receive automatic firmware updates. I don't know if Google is still on the ball there. The Nest acquisition was confusing. Have the Google Wifi and Nest Wifi teams been merged?
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.
I have not seen an exploit in the wild. I have at least 20 different servers unpatched (obviously) but the risk is blown way out of proportion. There are a number of mitigation options available.
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?
Jesus H Christ! the bug is a narrow use-after-free race that needs SYNs carrying ipv4 options to make it to the box. I do not need an army of honeypots to tell you it most likely doesnt to have a way into a classic 443 machine... come on now.
I know something. Every fucking server with public facing infrastructure is not getting hacked left and right at the moment.
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.
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've seen another poster successfully updating their Kernel from Ubuntu's "proposed" branch which already has the fix. God knows why they don't merge it into stable.
That's what I call Steve Jobs style PR / Marketing you deflect the problem by making another problem to make it seem like you're fully aware. "You're holding the phone wrong"
Can't tell if Ubuntu is smart for deferring this patch until a bigger periodic release because there's no evidence it's been exploited and its exploitability is quite limited or if Ubuntu is dumb because there's a lot of publicity around this CVE and it comes off as failing to read the room.
> 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.
For those not aware: Freenode.net is not Freenode as we all knew and loved it from the early 2000s to 2021. A hostile take-over of the Freenode LLC resulted in the loss of the domain name and some corporate assets. And the hostile takeover person, Andrew Lee, deleted the Freenode database. It no longer exists.
"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 DROP
Yeah, I thought we stopped posting freenode links here on HN a while ago. Kinda surprised about this one (especially since it is covered in detail elsewhere as well)
FreeBSD is quietly prevalent in commercial and government settings. Juniper and NetApp are just two renowned examples. There have been and are many others.
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.
Okay... can you name a specific thing? I'm confused. Nomad and Kubernetes both support Windows workers well. Kubernetes, afaik, doesn't support something like OpenBSD in a common flavor like RKE.
Kubernetes' core pieces of userspace software, not with any implied support from the Kubernetes project, also run on illumos, FreeBSD (and HardenedBSD), and OpenBSD.
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.
How do we feel now about having pointless services listening for no good reason on open ports?
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?
> about having pointless services listening for no good reason
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.
I was previously Ubuntu-by-default for my random Linux boxen, but going to upgrade things and finding that Ubuntu didn't have a patch has shaken my faith in it. I probably won't choose it for new servers in the future.
It's rather uninteresting to note, once again, that Ubuntu has decided to do this. I would like to know the (official, if any - unofficial/speculative otherwise) reason WHY they have not.
It 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?
Maybe a government doesn't want them to do that.
Question:
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.
Ubiquity routers and APs do. Also schedulable backups.
Granted they are pro-sumer devices, not strictly consumer.
Is it a cause of concern? Yes. Will you get hacked? Most likely not.
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.
I know the context here is consumer routers, but for those reading who might be running a server, or a homelab, or anything that does accept connections from outside, I want to make it clear that "most likely not" turns into "likely trivial if targeted" for servers.
Can you give examples of kernel bugs that can be targeted on an otherwise locked down system? Let's say something running just LAMP and all other ports closed off with a software firewall. Even the one in this article seems very tricky to actually exploit.
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
Any TCP packet (with IP options) you can send to a Linux kernel that doesn't get DROP'd by netfilter makes you technically vulnerable.
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 servers don't have as much protection or have other open ports accessible.
This is one of the biggest benefits of using OpenWRT. They update the entire stack like every other month or so you’re never on an ancient kernel or utils.
I checked yesterday. Updates were not ready yet. I took the chance to upgrade from 21 to 25 anyway.
Google Wifi used to be good about that. I even got a notification for when my AP was being EOL'd and would no longer receive automatic firmware updates. I don't know if Google is still on the ball there. The Nest acquisition was confusing. Have the Google Wifi and Nest Wifi teams been merged?
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.
even more concerning would be the ones who run closed source os but never update.
at least with an open source os there are more paths forward.
most of the routers are patched by ISPs directly. also: they are usually not x86 architecture - so not all exploits are possible.
A lot of them run BSD, not linux, which wasn't affected
BSD never ever has security issues so kernel updates are never necessary?
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?
Google tells me almost none of them run BSD and nothing I've ever heard of, much less seen.
But what do I know about it beyond that?
Nah I wouldn't worry about I'm sure they're fine
Good thing everything on the lan side is fully patched all the time. God bless those vigilant smart device manufacturers, especially the tv guys
Same for Flock cameras, running a 2017 kernel.
I have not seen an exploit in the wild. I have at least 20 different servers unpatched (obviously) but the risk is blown way out of proportion. There are a number of mitigation options available.
> I have not seen an exploit in the wild.
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?
Jesus H Christ! the bug is a narrow use-after-free race that needs SYNs carrying ipv4 options to make it to the box. I do not need an army of honeypots to tell you it most likely doesnt to have a way into a classic 443 machine... come on now.
Yeah, there's definitely more to the story about exploitability that Anthropic isn't telling us. RHEL didn't release a patch until yesterday either.
“Definitely”. How exactly? Do you know something?
I know something. Every fucking server with public facing infrastructure is not getting hacked left and right at the moment.
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.
They also don't provide any mitigation possibilities or instructions... RHEL has one method here: https://access.redhat.com/security/vulnerabilities/RHSB-2026...
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've seen another poster successfully updating their Kernel from Ubuntu's "proposed" branch which already has the fix. God knows why they don't merge it into stable.
> I've also not seen anyone else make this claim.
That's what I call Steve Jobs style PR / Marketing you deflect the problem by making another problem to make it seem like you're fully aware. "You're holding the phone wrong"
Discussion (842 points, 422 comments) https://news.ycombinator.com/item?id=50337608
Can't tell if Ubuntu is smart for deferring this patch until a bigger periodic release because there's no evidence it's been exploited and its exploitability is quite limited or if Ubuntu is dumb because there's a lot of publicity around this CVE and it comes off as failing to read the room.
https://ubuntu.com/blog/fixes-available-in-proposed-pocket-f...
you can use proposed pocket as per this for latest LTS releases
switched to Debian not that long ago. Living the life now.
It's not a zero-day if it's not the zeroth day anymore :-)
According to wikipedia[1]:
> 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.
[1] https://en.wikipedia.org/wiki/Zero-day_vulnerability
For those not aware: Freenode.net is not Freenode as we all knew and loved it from the early 2000s to 2021. A hostile take-over of the Freenode LLC resulted in the loss of the domain name and some corporate assets. And the hostile takeover person, Andrew Lee, deleted the Freenode database. It no longer exists.
"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.
The volunteer and staff that made up Freenode moved to libera.chat, which is the defacto freenode replacement, if anyone wanna know.
Yeah, I thought we stopped posting freenode links here on HN a while ago. Kinda surprised about this one (especially since it is covered in detail elsewhere as well)
Does ucore hace a patch yet? I justfinished moving all my stuff off ubuntu to ucore last week
They are busy migrating to rust, ubuntu will be safe soon, don't worry anyone!
CiCD of Gentoo based systems patched this as early as any other system.
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.
Yeah attackers might not want to bother spending tokens on some niche OS but security thru obscurity only gives you so much
FreeBSD is quietly prevalent in commercial and government settings. Juniper and NetApp are just two renowned examples. There have been and are many others.
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.
_> but security thru obscurity
Arrogance is stupidity.
Do you mean Kubernetes on Windows?
Obviously not.
Nomad and Kubernetes orchestrate Linux containers using features of the Linux kernel (except where Windows kernel support has also been added).
Maybe you're thinking of jails? I'm not sure if there's any mainstream/popular distributed orchestration systems for those.
Okay... can you name a specific thing? I'm confused. Nomad and Kubernetes both support Windows workers well. Kubernetes, afaik, doesn't support something like OpenBSD in a common flavor like RKE.
Kubernetes' core pieces of userspace software, not with any implied support from the Kubernetes project, also run on illumos, FreeBSD (and HardenedBSD), and OpenBSD.
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.
How do we feel now about having pointless services listening for no good reason on open ports?
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.
> about having pointless services listening for no good reason
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.
This CVE has nothing to do with leaving random ports open. "Tightening up" will not protect vulnerable servers.
> For example Linux works totally fine without running dhcpcd
how you refresh dhcp lease if there is no service taking care of ? Why you think DHCP is pointless ?
Use a static up when at home. I would agree it’s a bit pointless though.
systemd-networkd hides
These comments always misunderstand the long tail of the individual end user.
Just block the ingress IPv4 packets with IP options using nftables or iptables and move on.
Why does everything has to come with so much drama these days.