Rendered at 02:50:51 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
debinguy 1 hours ago [-]
I find it odd that no public discussions are highlighting that iptables or nftables can drop this before the kernel CVE is exploitable by a U32 drop rule in raw PREROUTING...
sudo iptables -t raw -I PREROUTING -p tcp -m u32 ! --u32 "0>>24&0x0F=5" -j DROP
mort96 50 minutes ago [-]
Does a normal "default deny all incoming" rule with e.g UFW or nftables achieve the same thing?
h4kunamata 5 minutes ago [-]
Silly those who use Ubuntu in 2026.
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.
c0l0 6 hours ago [-]
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?
_ink_ 4 hours ago [-]
Maybe a government doesn't want them to do that.
chews 1 hours ago [-]
N ot S aying A nything...
harry8 4 hours ago [-]
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.
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.
LaurensBER 3 hours ago [-]
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.
majorchord 3 hours ago [-]
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.
dwedge 3 hours ago [-]
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
majorchord 3 hours ago [-]
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 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.
cjbprime 2 hours ago [-]
Does the bug we're talking about not count as an example for some reason?
harry8 2 hours ago [-]
Don't a lot of consumer routers allow for remote connection for tech help trouble-shooting?
How about forwarding a port for wireguard or ssh?
j45 2 hours ago [-]
It's a massive risk, and only a matter of time. Especially for hardware that's no longer updated firmware wise.
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.
0rzech 33 minutes ago [-]
Every consumer router-wirelessAP I've seen runs linux.
I never see security upgrades for the kernels they use. Not one. Not ever.
Turris [1] has been updating their routers for years.
Mosty probably: not. Traffic passes throught the ASIC, usually it is not processed on CPU or custom code. Unlike typical web servers, that reduces the attack surface as there aren't software parsers (a common place where vulnerabilities hide). Additionally the OS may have additional protection measures, such as signing each binary, signing the booting image and limiting which syscalls can be done by any binary.
wps 4 hours ago [-]
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.
davrosthedalek 4 hours ago [-]
I checked yesterday. Updates were not ready yet. I took the chance to upgrade from 21 to 25 anyway.
za_creature 50 minutes ago [-]
It's a bit of bad luck tbh; they just made a point release a few days prior to the bug being announced, with kernel .112
deepsun 3 hours ago [-]
Ubiquity routers and APs do. Also schedulable backups.
Granted they are pro-sumer devices, not strictly consumer.
cpburns2009 2 hours ago [-]
My UDM-Pro had an update available yesterday. I don't know if it's related to the CVE or the shit eMudhra CA.
harry8 2 hours ago [-]
This is a good point, thanks. We know one does which beats none.
wahern 3 hours ago [-]
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.
kevin_thibedeau 2 hours ago [-]
This is why I use a fanless PC as my internal router. I have complete control and get timely kernel updates from a responsible distro.
toofy 3 hours ago [-]
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.
qw3rty01 3 hours ago [-]
A lot of them run BSD, not linux, which wasn't affected
harry8 3 hours ago [-]
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?
harry8 2 hours ago [-]
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?
markasoftware 4 hours ago [-]
Nah I wouldn't worry about I'm sure they're fine
snapplebobapple 4 hours ago [-]
Good thing everything on the lan side is fully patched all the time. God bless those vigilant smart device manufacturers, especially the tv guys
tonymet 40 minutes ago [-]
i admit they don't enumerate their patches well, but the major residential router vendors do regular updates , usually indicated with "security fixes" .
unfortunately most lack SSH access or a real ability to test the kernel patch version.
pengaru 2 hours ago [-]
eero updates its APs OTA, they run linux. Even stuff sold > 5 years ago is still receiving updates.
full disclosure: they're my employer
iAMkenough 3 hours ago [-]
Same for Flock cameras, running a 2017 kernel.
iberator 3 hours ago [-]
most of the routers are patched by ISPs directly.
also: they are usually not x86 architecture - so not all exploits are possible.
harry8 2 hours ago [-]
Never seen an ISP patch a router. Ever.
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.
edoceo 42 minutes ago [-]
I'm on Comcast in USA, I BYOD for the router and it's a Netgear C3500 (I think). It gets new firmware pushed to it from Comcast. Can't even load your own manually.
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.
rf15 5 hours ago [-]
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.
giancarlostoro 6 hours ago [-]
> 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"
worthless-trash 2 hours ago [-]
No, one blames the user, the other is behing honest.
8 hours ago [-]
jimrandomh 3 hours ago [-]
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.
Surely there is a more reputable source for this story than a blog stapled to a stolen IRC network
pelagicAustral 5 hours ago [-]
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.
secabeen 5 hours ago [-]
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.
worthless-trash 2 hours ago [-]
Rhel had patches on saturday.
SP3269 4 hours ago [-]
“Definitely”. How exactly? Do you know something?
pelagicAustral 4 hours ago [-]
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.
majorchord 3 hours ago [-]
> 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?
handoflixue 2 hours ago [-]
The recent wave of vulnerabilities has actually prompted a lot of people to set up honeypots, monitoring, etc. and the rate of actual exploits has been notably very low for the general public.
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!
dboreham 46 minutes ago [-]
I've been counting inbound packets with options set on my edge routers for a couple of days. So far: zero.
pelagicAustral 3 hours ago [-]
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.
ranger_danger 2 hours ago [-]
Except I was able to use the PoC to exploit several of my "classic 443 machines" sitting on the internet, like millions of other servers out there.
evilDagmar 1 hours ago [-]
You had services running that actually use MPTCP?
drnick1 38 minutes ago [-]
I have been running pure Debian for years on my router/home server. Ubuntu is a superset of Debian that adds mostly adds stuff that is irrelevant for a networking device. Just stick to base distributions unless you are a very good reason not to.
you can use proposed pocket as per this for latest LTS releases
mbac32768 3 hours ago [-]
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.
superkuh 7 hours ago [-]
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
maeln 6 hours ago [-]
The volunteer and staff that made up Freenode moved to libera.chat, which is the defacto freenode replacement, if anyone wanna know.
dark-star 5 hours ago [-]
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)
TutleCpt 5 hours ago [-]
switched to Debian not that long ago. Living the life now.
warpspin 5 hours ago [-]
It's not a zero-day if it's not the zeroth day anymore :-)
majorchord 3 hours ago [-]
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.
Does ucore hace a patch yet? I justfinished moving all my stuff off ubuntu to ucore last week
4 hours ago [-]
jon128 7 hours ago [-]
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.
InsidiousWombat 6 hours ago [-]
Yeah attackers might not want to bother spending tokens on some niche OS but security thru obscurity only gives you so much
jon128 6 hours ago [-]
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.
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.
doctorpangloss 5 hours ago [-]
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.
jon128 5 hours ago [-]
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.
TZubiri 2 hours ago [-]
RIP
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.
cpburns2009 2 hours ago [-]
Does Debian still make it annoying to use "nonfree" drivers?
lousken 6 hours ago [-]
They are busy migrating to rust, ubuntu will be safe soon, don't worry anyone!
beaconflint 5 hours ago [-]
[flagged]
h1bslop 7 hours ago [-]
[flagged]
Gys 7 hours ago [-]
'Vulnerabilities will always arise. What matters is the speed and success with which they are resolved – and nobody provides fixes available faster than Canonical.'
john_strinlai 7 hours ago [-]
this is a weak comment in general, but especially in this case considering ubuntu has a subscription where people are paying for timely security updates
TacticalCoder 6 hours ago [-]
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.
viraptor 6 hours ago [-]
> 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.
gwbas1c 5 hours ago [-]
This CVE has nothing to do with leaving random ports open. "Tightening up" will not protect vulnerable servers.
InsidiousWombat 6 hours ago [-]
> 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 ?
smackeyacky 6 hours ago [-]
Use a static up when at home. I would agree it’s a bit pointless though.
nijave 5 hours ago [-]
systemd-networkd hides
halJordan 5 hours ago [-]
These comments always misunderstand the long tail of the individual end user.
ay 4 hours ago [-]
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.
majorchord 2 hours ago [-]
Red Hat claims[1] that's not enough:
> 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.
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.
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?
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.
[1] https://www.turris.com
Granted they are pro-sumer devices, not strictly consumer.
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.
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?
unfortunately most lack SSH access or a real ability to test the kernel patch version.
full disclosure: they're my employer
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.
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.
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"
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!
you can use proposed pocket as per this for latest LTS releases
"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.
> 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
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.
_> but security thru obscurity
Arrogance is stupidity.
Maybe you're thinking of jails? I'm not sure if there's any mainstream/popular distributed orchestration systems for those.
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.
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.
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.
how you refresh dhcp lease if there is no service taking care of ? Why you think DHCP is pointless ?
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...