Rendered at 22:46:00 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
debinguy 21 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
lambdaone 13 hours ago [-]
It's one of the major selling points of Linux that Linux admins can do this even if their OS vendor won't, but the whole point of having a distro is to stop you from needing to roll your own solutions, or to have to maintain constant vigiliance to be even remotely secure.
throwaway63467 11 hours ago [-]
Just patched it everywhere on my servers last night. It’s getting increasingly more difficult to run things exposed to the internet, I get so many “sorry we’ve been hacked your data was stolen” e-mails recently it’s crazy, we must have armies of people combing through the web with AI attack tools.
LtdJorge 13 hours ago [-]
For anyone that doesn't know, this reads the header and drops the packet if the length isn't 5*4 bytes, meaning it includes options.
mort96 21 hours ago [-]
Does a normal "default deny all incoming" rule with e.g UFW or nftables achieve the same thing?
ranger_danger 18 hours ago [-]
"default deny incoming" would apply to the filter INPUT chain, and there are several other chains that run before that one (raw, conntrack, mangle, nat), so it's better to use an explicit iptables or nft rule targeting the earliest "raw PREROUTING" chain.
Do note that eBPF can still bypass netfilter entirely, as can containers, or any process using a separate network namespace.
mort96 15 hours ago [-]
The reason I ask is that I have devices out there like that today and I need to know whether I should be freaking out or be completely calm.
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.
> 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.
InsidiousWombat 11 hours ago [-]
the bug is in processing TCP connections to the host. The chain you drop the packet doesn't matter
ranger_danger 6 hours ago [-]
> The chain you drop the packet doesn't matter
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 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.
mort96 6 hours ago [-]
Sounds like if I don't have other rules which allow the incoming connection, and processes running on the host are outside my threat model, I'm safe.
wolvoleo 19 hours ago [-]
No it doesn't insert any rule like that by default though you could of course configure ufw to do so.
zamadatix 18 hours ago [-]
I think they were saying if one uses such a rule in general (as is normal) but looking into it some more it seems it may actually be the default out of the box as well as long as you've enabled UFW:
> 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.
The more specific rule is probably more useful if you do intend to expose a TCP port though.
wolvoleo 17 hours ago [-]
Ah I misunderstood the question, yes if you are not having any TCP ports exposed it's ok of course.
mort96 14 hours ago [-]
Is that actually true? Something still handles those packets, are they dropped by the firewall before or after the vulnerable code?
zamadatix 7 hours ago [-]
It'll get dropped before the session creation as it's a prerouting rule.
bbrake 5 hours ago [-]
many news stories fail to mention mitigations, i wished there was more discussion about mitigation over 'just patching'
Lord_Zero 20 hours ago [-]
I respect that there is a quick fix I can do myself with iptables. However, I don't want to have to do that. I run Ubuntu with automatic security patches enabled, I trust the Ubuntu team to issue quick fixes and my server to be patched most of the time while I am asleep. I don't want to have to manually edit my server configuration to patch security holes and have to remember all these little knobs when I get EOL and have to rebuild my server.
majorchord 18 hours ago [-]
> I trust the Ubuntu team to issue quick fixes
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.
retube 19 hours ago [-]
> I trust the Ubuntu team to issue quick fixes and my server to be patched most of the time while I am asleep
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.
snottynose 4 hours ago [-]
They also choose to ask for your donation when you download the software, plus a suggested amount. I guess we can infer from your response which direction you chose to drag the slider.
whatshisface 14 hours ago [-]
Handing over a hot lead and a set of good information is not, "free!"
voakbasda 7 hours ago [-]
It was, however, a reasonable bargain to make, but that is no longer the case when they do not hold up their end of the deal like this.
aucisson_masque 15 hours ago [-]
The same as you pay for Debian.
ranger_danger 19 hours ago [-]
I also add the same rule for OUTPUT to prevent any misbehaving apps from trying to break things.
> 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.
amluto 18 hours ago [-]
What does the installation or lack thereof of firejail have to do with anything? You can do this with plain unshare + iptables.
ranger_danger 3 hours ago [-]
> You can do this with plain unshare + iptables.
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.
lambdaone 13 hours ago [-]
At this point, just the failure to patch this single vulnerability is enough to make me write Ubuntu off as a viable distribution. Volunteer-run distros can fix this, why not a well-resourced company? It's not as if they haven't had the time to fix it, or that porting the fix to their current kernels would be particularly difficult.
littlecranky67 12 hours ago [-]
This is the final nail in the coffin. I already order my new vservers with debian. I'll keep the existing ones on ubuntu for now, but will not consider ubuntu for anything server side in the future. My reasoning was "Debian is volunteers, they probably won't release fixes as fast as a commercial entity" - obviously the reasoning is backwards.
But I also must say, I am not giving a single dollar to ubuntu nor did I ever do so, so it is also perfectly valid for Ubuntu to not give a damn about me.
c0l0 1 days 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?
wolvoleo 19 hours ago [-]
I think they just didn't want to bother getting it in an out of band procedure so they're waiting for a patch window.
Which is a bad choice considering the impact imo.
The problem is as organisations grow, the more governance types get involved and slow things down with arbitrary rules.
cm2187 14 hours ago [-]
But surely they see the backlash on HN and reddit. I find it odd that they don't seem to communicate at all on that.
dataengineer56 11 hours ago [-]
Many people will not pay much attention to the opinion of the average Reddit user these days.
cm2187 10 hours ago [-]
Deservedly. But the HN audience is generally on the other side of the median of the IQ distribution than Reddit’s.
LtWorf 2 minutes ago [-]
I think you'd fit right in on r/Gifted.
mrguyorama 5 hours ago [-]
Believing this in any way is it's own evidence of it being untrue.
philipallstar 13 hours ago [-]
The governance types maybe don't inhabit HN in high numbers.
lambdaone 13 hours ago [-]
Or simply don't care.
bibelo 12 hours ago [-]
The PHP2SHELL fix was released on time.
So indeed, there's probably some reason
PcChip 10 hours ago [-]
What if it turns out they have a very good reason but can’t talk about it yet
wolvoleo 8 hours ago [-]
Then they could say they have a very good reason but can't elaborate on it yet.
_ink_ 1 days ago [-]
[flagged]
chews 21 hours ago [-]
N ot S aying A nything...
harry8 24 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 23 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 23 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 23 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 23 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 22 hours ago [-]
Does the bug we're talking about not count as an example for some reason?
dwedge 23 minutes ago [-]
The comment addressed this
harry8 22 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?
userbinator 19 hours ago [-]
Those are usually not enabled by default.
AFAIK all the backdoors which have been found in some models are only accessible from the LAN side, and if you have an attacker inside the network, it's already too late.
TheDong 13 hours ago [-]
> if you have an attacker inside the network, it's already too late.
It shouldn't be though. Just because my smart lightbulb has an RCE and is isolated on its own VLAN with the router doesn't mean it should be able to attack the router and escalate to access my devices on other VLANs. It should only be able to do damage limited within its own vlan.
ranger_danger 18 hours ago [-]
> if you have an attacker inside the network, it's already too late.
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.
j45 21 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 20 hours 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 meticulously 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.
duskwuff 18 hours ago [-]
> 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.
I'd love for that to be true. Unfortunately, a lot of consumer routers are fairly straightforward Linux systems with no particular attempts at hardening.
tonymet 16 minutes ago [-]
but he has a point that if the ASIC is doing the TCP header offload, wouldn't this particular CVE not be applicable?
majorchord 18 hours ago [-]
The bug in question is not mitigated by any userspace actions (like signing binaries or boot images) or even by limiting syscalls, and all it takes is a listening socket on the device from either direction (inside or outside the network) to get root since router-destined packets are always processed by the CPU.
lxgr 13 hours ago [-]
All traffic? In particular, I'd expect new connection establishment to go through a software path, looking up port forwarding and firewall rules etc. and creating hardware forwarding table entries if applicable.
wps 24 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.
Saris 10 hours ago [-]
The downside is it warns me if I update things will probably break and to take a backup, I've always been wary of updating my openwrt router because of that.
fn-mote 10 hours ago [-]
No kidding make a backup. The warning is sensible.
I haven’t had problems upgrading in at least 4 years. There’s a screen where you click a button to auto-upgrade.
Just get it installed.
davrosthedalek 23 hours ago [-]
I checked yesterday. Updates were not ready yet. I took the chance to upgrade from 21 to 25 anyway.
za_creature 21 hours 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
user2722 11 hours ago [-]
You may want to try to look at Gl.inet routers. I'm not sure yet what is their modus operandi, but at least Flint 2 has both their official firmware (with Mediatek's SDK, I guess) and a vanilla Openwrt version -- on their company page.
Their features (Glinet's mesh) are not compatible but it does seem better than just drop support totally.
There also seems to be some involvement in the upbringing of openwrt support -- so it's not a hands-off approach, but on the other hand I'm only looking at Flint 2 firmware/OS development.
Additionally, their Flint 3e uses Qualcomm so the route it takes may be different -- though I hope not!!!
Now, if we are talking about my ISP router/modem....... I'd rather not think about it.
PS: Gl.inet also has a router with fiber optic. Not sure how that would work if I wanted to throw my ISP's router/modem out the window.
deepsun 22 hours ago [-]
Ubiquity routers and APs do. Also schedulable backups.
Granted they are pro-sumer devices, not strictly consumer.
roryirvine 13 hours ago [-]
According to its logs, my bargain basement Huawei 4G router from 2019 got an update last week.
I hope that most of these devices actually do update themselves automatically, and people just aren't noticing. (Whether the updates are any good is another matter!)
angry_octet 10 hours ago [-]
It got an update, but from whom?
cpburns2009 22 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 22 hours ago [-]
This is a good point, thanks. We know one does which beats none.
kevin_thibedeau 22 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.
Maken 10 hours ago [-]
I have a MikroTik router at home, and they have already patched this [1]
My home router is managed by my ISP. They can, and do, remotely upgrade routers in the middle of the night.
wahern 23 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.
qw3rty01 23 hours ago [-]
A lot of them run BSD, not linux, which wasn't affected
harry8 23 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?
wolvoleo 19 hours ago [-]
> BSD never ever has security issues so kernel updates are never necessary?
Of course it does. But it was not affected in this particular case.
12 hours ago [-]
harry8 22 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?
wolvoleo 19 hours ago [-]
BSD is very popular for open router ecosystems, like pfSense, opnSense.
Some more commercial ones (pfsense is commercial) use it too like juniper junos.
harry8 16 hours ago [-]
We’re talking about consumer router/wireless APs here.
Fnoord 15 hours ago [-]
Any wireless AP is going to run Linux because BSD has had a tough time with anything better than 802.11n
Any router/switch is going to be running an ancient Linux kernel, which isn't patched. EdgeOS for example, won't be patched. The old Brocade/Ruckus switches I got here, won't have this patched. I'm holding my breath for my Unifi APs.
ahoka 15 hours ago [-]
Last consumer router that ran any kind of BSD based firmware was probably Apple Airport and that was a long time ago.
nullpoint420 19 hours ago [-]
could be intentional, even
markasoftware 24 hours ago [-]
Nah I wouldn't worry about I'm sure they're fine
snapplebobapple 24 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
toofy 23 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.
pengaru 22 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
Chaosvex 11 hours ago [-]
Eero needs to make sure that they're the only ones exfiltrating data from their products. :^)
pengaru 44 minutes ago [-]
While it's certainly not the right product for the openwrt crowd wanting to flash their own firmware and look under the covers, I wouldn't work here if we were obviously doing such things to the degree your comment implies.
iAMkenough 23 hours ago [-]
Same for Flock cameras, running a 2017 kernel.
tonymet 21 hours 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.
iberator 22 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 22 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 21 hours 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.
harry8 20 hours ago [-]
BYOD = bring your own device? And yet your isp pushes updates to it?
Defintely seems potentially better than no updates at all.
How do you know if you have a wide open CVE they're ignoring, like it's claimed ubuntu are doing?
duskwuff 17 hours ago [-]
> BYOD = bring your own device? And yet your isp pushes updates to it?
Perhaps better characterized as "buy your own device". Cable ISPs will only support a limited set of modems on their network, and they're fully managed by the ISP, both in terms of software and configuration.
edoceo 17 hours ago [-]
Correct, and they are limited in features. I'm going to swap out this combo-modem+WiFi and get a dedicated -modem and then have a different device as my "edge" router/NAT
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 1 days 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.
jeroenhd 16 hours ago [-]
They have over a hundred kernel configurations (multiplied by aarch64 vs amd64), many of which going back years, to do testing on. That probably doesn't help. People comparing them to open source projects like Arch and nixOS which support maybe one or two versions per platform are making a false comparison.
So far they're two days later than IBM/Red Hat. Not great, for sure, but they seem to be that far behind compared to the competition just yet.
If they push a backport that kills a million set top boxes because of changes in the network stack, they're not much better off than if they work a couple more days on testing.
giancarlostoro 1 days 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 21 hours ago [-]
No, one blames the user, the other is behing honest.
ranger_danger 3 hours ago [-]
Ubuntu finally updated their page (https://ubuntu.com/security/CVE-2026-98432) today... not to release any actual fixes, but to finally add mitigation steps... and they use the same "does not protect against all attacks" wording like RHEL did without elaborating.
hanumseous 12 hours ago [-]
the boundary does elaborate, its a network namespaace scopep statement.
and the rule only filter traffic to the host netns, so, pod to pod traffic is untoched, and forwarded to pods filtering depends on the cluster network config.
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.
sheepscreek 20 hours ago [-]
> I have not seen an exploit in the wild...but the risk is blown way out of proportion
That's a very naive view on it (now) and I'll try my best to explain why.
The bad actors can discover multiple 0-days on the fly to gain access to an employer/company infrastructure with valuable data/information, or in the case of Binance, crypto. They could chain multiple such attacks going from one-company/provider to another, to another, to eventually reach their target.
To anyone interested, this is good reading material on the topic:
(1) study the Binance hack in detail
(2) OpenAI huggingface hack - focus on 0-day chaining
majorchord 23 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 22 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 21 hours ago [-]
I've been counting inbound packets with options set on my edge routers for a couple of days. So far: zero.
pelagicAustral 22 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 22 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 21 hours ago [-]
You had services running that actually use MPTCP?
ranger_danger 6 hours ago [-]
MPTCP is not a requirement for the bug, but yes, I had several, as I use it to aggregate multiple ISP connections.
> Multipath TCP is not a required condition for this flaw.
I contemplated not even responding to you because of how unbelievably abusive and rude I have watched you be on IRC to me and many others for literally decades, and was a big reason why I quit, but I decided this issue was more important for everyone else's sake that I should still speak up.
GordonS 15 hours ago [-]
I think it's used internally within Caddy?
yxhuvud 17 hours ago [-]
Not uncommon, it is enabled by default in Go.
secabeen 1 days 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 21 hours ago [-]
Rhel had patches on saturday.
SP3269 1 days ago [-]
“Definitely”. How exactly? Do you know something?
pelagicAustral 24 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.
KAMSPioneer 14 hours ago [-]
What was the timeline for the release of WannaCry following the exposure of ETERNALBLUE and DOUBLEPULSAR...?
I accept that one would expect substantially shorter timelines in the age of AI, but given that WannaCry is suspected of being state-funded and even then: 1) it took a month to appear and 2) ETERNALBLUE and DOUBLEPULSAR were essentially already finished, weaponized malware off the shelf.
All of this to say that just because you don't see mass exploitation right this second doesn't mean there isn't a wormable exploit that needs patching. WannaCry didn't exist until it did, and suddenly everyone who failed to patch beforehand looked foolish.
lambdaone 12 hours ago [-]
You have not knowingly seen an exploit in the wild. Competent attackers can be right inside your OS, and many other devices containg within the same network as a result, without you knowing it; persistenly so if they want to.
jimrandomh 23 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.
heatpump5n 14 hours ago [-]
Me too, guess I'll go back to Debian, it's safer. Really disappointing.
jordemort 21 hours ago [-]
Surely there is a more reputable source for this story than a blog stapled to a stolen IRC network
xet7 1 hours ago [-]
I installed newest mainline kernel, it did work for me.
sudo add-apt-repository ppa:cappelikan/ppa -y
sudo apt update
sudo apt install mainline -y
mainline check
mainline install 7.3.1
sudo apt -f install
reboot
als0 56 minutes ago [-]
Who is cappelikan? Why should I trust them?
pjmlp 10 hours ago [-]
It is open source, those complaing, have they given any money to sponsor the fix?
Yes, they should probably by now have shipped it, yet all those complaints are the usual entitled folks that only leech distros.
tapoxi 10 hours ago [-]
Yes? Ubuntu is the one with an enterprise option. Debian, their free and community supported upstream has already patched this.
pjmlp 9 hours ago [-]
How many of those complaining have actually paid for Enterprise Ubuntu?
Good for Debian, they were not required to.
fl0ki 5 hours ago [-]
Users: I never said thank you.
Debian: And you'll never have to.
drnick1 21 hours ago [-]
I have been running pure Debian for years on my router/home server. Ubuntu is a superset of Debian that mostly adds stuff that is irrelevant for a networking device. Just stick to base distributions unless you are a very good reason not to.
Gigachad 17 hours ago [-]
Ubuntu made more sense when you installed end user apps from the apt repos and wanted updates more than every 2 years. These days with Flatpak you are better off on Debian.
Why are we linking to freenode? Did people forget what went down?
superkuh 1 days 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 1 days ago [-]
The volunteer and staff that made up Freenode moved to libera.chat, which is the defacto freenode replacement, if anyone wanna know.
wolvoleo 19 hours ago [-]
Yeah and within 3 weeks it was back to the same old, like freenode had always been libera <3 And no more bullshit and hassle which Lee brought.
I was afraid the community would get splintered out but it didn't. The quick decisive action in establishing libera really helped that. Only a few channels left to go somewhere else (like alpine linux)
I really loved this example of a community massively saying Nope and just avoiding a hostile takeover altogether. Unfortunately it doesn't usually happen so well.
account42 10 hours ago [-]
Unfortinatly no. A lot of channels moved to OFTC or other networks instead (and some quit IRC entirely) so Libera isn't the one stop for open source IRC that Freenode was.
account42 10 hours ago [-]
> And the hostile takeover person, Andrew Lee, deleted the Freenode database.
But only after it was clear that most channels were leaving anyway. In a way, that was the only good thing he did in this mess: reduce fragmentation that we would have gotten as some stuck to Freenode.
dark-star 1 days 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)
soraminazuki 16 hours ago [-]
Freenode is the worst possible source for discussing open source issues considering the harm its new owners caused to open source communities.
But lately, the Freenode fiasco has been on the back of my mind from time to time. If the same thing happened today, a good chunk of the comments would be cheering for Freenode. Almost every single article critical of the takeover would be flagged too.
mbac32768 23 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.
TutleCpt 1 days ago [-]
switched to Debian not that long ago. Living the life now.
warpspin 1 days ago [-]
It's not a zero-day if it's not the zeroth day anymore :-)
majorchord 23 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.
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 1 days ago [-]
Yeah attackers might not want to bother spending tokens on some niche OS but security thru obscurity only gives you so much
jon128 1 days 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 1 days 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 1 days 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.
doctorpangloss 5 hours ago [-]
there's nothing obvious about this haha
jon128 4 hours ago [-]
Yeah, obviously.
The other thing that was obvious earlier was that the OS mentioned previously was not Windows.
snapplebobapple 1 days ago [-]
Does ucore hace a patch yet? I justfinished moving all my stuff off ubuntu to ucore last week
sylware 12 hours ago [-]
Erk! the CVE database you cannot read without a whatwg web engine... shame on them.
1 days ago [-]
TZubiri 22 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 22 hours ago [-]
Does Debian still make it annoying to use "nonfree" drivers?
atoav 17 hours ago [-]
This is why I am going to migrate my 4 webservers to Debian soon.
riffic 20 hours ago [-]
maybe canonical needs a wackier interview and hiring process.
ReDress 17 hours ago [-]
[dead]
beaconflint 1 days ago [-]
[flagged]
150g2 14 hours ago [-]
[dead]
h1bslop 1 days ago [-]
[flagged]
Gys 1 days 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 1 days 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
lousken 1 days ago [-]
[flagged]
TacticalCoder 1 days 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 1 days 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.
InsidiousWombat 1 days 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 1 days ago [-]
Use a static up when at home. I would agree it’s a bit pointless though.
account42 10 hours ago [-]
[dead]
nijave 1 days ago [-]
systemd-networkd hides
halJordan 1 days ago [-]
These comments always misunderstand the long tail of the individual end user.
warkdarrior 17 hours ago [-]
We would be much more secure if we didn't have those pesky users.
gwbas1c 1 days ago [-]
This CVE has nothing to do with leaving random ports open. "Tightening up" will not protect vulnerable servers.
justauserid 19 hours ago [-]
tl;dr: What is a good vm/container tool (and OS to live inisde that) for a 16GB RAM m1 pro mac that doesn't guzzle up the resources and is safe/easy enough.
-----
I am thinking of setting up a VM/container on my 16GB M1 Pro mac. The purpose mainly is to move harnesses (and the world of NPM et al) to it. Currently I am using few harnesses – Pi, OpenCode, Claude, Codex, and agy (mostly opencode, cluade code, and agy) – kinda controlled by sandbox-exec. It has wroked sufficiently well, as much as sandbox-exec can faciliate that. But what makes me unconfomrtables are things like:
1. I still have to give these harnesses write access to folders I'd otehrwise not be comfortable (esp. at the time of upgrade etc)
2. The face at which updates arrive – and then you accept that and that could be unsafe, you don't accept that and that could be unsafe
3. The asntronomical number of packages/dependencies that get updated everyday (sometimes in one hour) and it's needed for these harnesses. That makes me very nervous.
What tool + OS should I pick for my container environment? (I am comfortable with cli but have enver used VM before other than just installing and playing with it for a few minutes)
My main goals are:
1. less RAM usage (I don't have a lot left after normal OS and few programs I'd like to have running; often I also try some local models – sometimes just for STT; but just the 3-6B range) - so would appreciate if RAM overhead by the cotnainer OS and tool isn't a lot.
2. If possible use available disk space flexibily (without having to reserve in advnace; or I should be able to change/increase the image/container's disk usage capacity)
3. relatively safe and easy to use
4. Not having to create another mac user and then do this logout -> login (it's not comfortable, besides it increases RAM usage)
totetsu 17 hours ago [-]
and you thought you would just ask in a completly unrelated discussion?
try orbstack server or multipass if all this hasn't put you off canonical.
justauserid 16 hours ago [-]
> and you thought you would just ask
Yes, I did.
> in a completly unrelated discussion
I disagree with this point. One of the reasons I have not been able to start on it is I don't know what OSes are secure for this purpose.
> orbstack server or multipass
I will try this. Thank you.
moi2388 16 hours ago [-]
Orbstack
ay 1 days 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 22 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.
eBPF programs can also bypass netfilter, as can different network namespaces (like as used by containers and some privsep/isolated software).
userbinator 19 hours ago [-]
locally-running malicious programs
That's Game Over already.
ranger_danger 19 hours ago [-]
It could be from a multi-part attack where someone combines an application-level RCE like php2shell, then sends the evil loopback packets to elevate to root.
perching_aix 18 hours ago [-]
if people decide so, certainly
cpburns2009 22 hours ago [-]
I know that's one mitigation technique, like disabling mptcp does. But does that fully prevent this exploit?
ay 2 hours ago [-]
The thing that is freed and then used-after-free in case the exploit is due to the data structure temporarily storing IP options from the original packet.
h4kunamata 20 hours 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.
sudo iptables -t raw -I PREROUTING -p tcp -m u32 ! --u32 "0>>24&0x0F=5" -j DROP
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.
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.
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.
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.
But I also must say, I am not giving a single dollar to ubuntu nor did I ever do so, so it is also perfectly valid for Ubuntu to not give a damn about me.
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?
Which is a bad choice considering the impact imo.
The problem is as organisations grow, the more governance types get involved and slow things down with arbitrary rules.
So indeed, there's probably some reason
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?
AFAIK all the backdoors which have been found in some models are only accessible from the LAN side, and if you have an attacker inside the network, it's already too late.
It shouldn't be though. Just because my smart lightbulb has an RCE and is isolated on its own VLAN with the router doesn't mean it should be able to attack the router and escalate to access my devices on other VLANs. It should only be able to do damage limited within its own vlan.
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.
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
10G looks a little less consumer-y. I'd imagine cisco, arista, etc do security updates if you want to go down that path.
AFAIK, none of them supports WPA Enterprise, which I'd consider necessary for enterprise-grade equipment.
OTOH, they are Open Source and Open Hardware, are still pretty powerful, and are much cheaper than enterprise HW.
PS. The proper link to their site in English is https://www.turris.com/en/ .
I'd love for that to be true. Unfortunately, a lot of consumer routers are fairly straightforward Linux systems with no particular attempts at hardening.
I haven’t had problems upgrading in at least 4 years. There’s a screen where you click a button to auto-upgrade.
Just get it installed.
Their features (Glinet's mesh) are not compatible but it does seem better than just drop support totally.
There also seems to be some involvement in the upbringing of openwrt support -- so it's not a hands-off approach, but on the other hand I'm only looking at Flint 2 firmware/OS development.
Additionally, their Flint 3e uses Qualcomm so the route it takes may be different -- though I hope not!!!
Now, if we are talking about my ISP router/modem....... I'd rather not think about it.
PS: Gl.inet also has a router with fiber optic. Not sure how that would work if I wanted to throw my ISP's router/modem out the window.
Granted they are pro-sumer devices, not strictly consumer.
I hope that most of these devices actually do update themselves automatically, and people just aren't noticing. (Whether the updates are any good is another matter!)
[1] https://mikrohub.io/mikrotik/changelog/long-term/7.24.6
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.
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?
Of course it does. But it was not affected in this particular case.
But what do I know about it beyond that?
Some more commercial ones (pfsense is commercial) use it too like juniper junos.
Any router/switch is going to be running an ancient Linux kernel, which isn't patched. EdgeOS for example, won't be patched. The old Brocade/Ruckus switches I got here, won't have this patched. I'm holding my breath for my Unifi APs.
at least with an open source os there are more paths forward.
full disclosure: they're my employer
unfortunately most lack SSH access or a real ability to test the kernel patch version.
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.
Defintely seems potentially better than no updates at all.
How do you know if you have a wide open CVE they're ignoring, like it's claimed ubuntu are doing?
Perhaps better characterized as "buy your own device". Cable ISPs will only support a limited set of modems on their network, and they're fully managed by the ISP, both in terms of software and configuration.
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.
So far they're two days later than IBM/Red Hat. Not great, for sure, but they seem to be that far behind compared to the competition just yet.
If they push a backport that kills a million set top boxes because of changes in the network stack, they're not much better off than if they work a couple more days on testing.
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"
That's a very naive view on it (now) and I'll try my best to explain why.
The bad actors can discover multiple 0-days on the fly to gain access to an employer/company infrastructure with valuable data/information, or in the case of Binance, crypto. They could chain multiple such attacks going from one-company/provider to another, to another, to eventually reach their target.
To anyone interested, this is good reading material on the topic:
(1) study the Binance hack in detail
(2) OpenAI huggingface hack - focus on 0-day chaining
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!
https://access.redhat.com/security/vulnerabilities/RHSB-2026...
> Multipath TCP is not a required condition for this flaw.
I contemplated not even responding to you because of how unbelievably abusive and rude I have watched you be on IRC to me and many others for literally decades, and was a big reason why I quit, but I decided this issue was more important for everyone else's sake that I should still speak up.
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.
I accept that one would expect substantially shorter timelines in the age of AI, but given that WannaCry is suspected of being state-funded and even then: 1) it took a month to appear and 2) ETERNALBLUE and DOUBLEPULSAR were essentially already finished, weaponized malware off the shelf.
All of this to say that just because you don't see mass exploitation right this second doesn't mean there isn't a wormable exploit that needs patching. WannaCry didn't exist until it did, and suddenly everyone who failed to patch beforehand looked foolish.
sudo add-apt-repository ppa:cappelikan/ppa -y
sudo apt update
sudo apt install mainline -y
mainline check
mainline install 7.3.1
sudo apt -f install
reboot
Yes, they should probably by now have shipped it, yet all those complaints are the usual entitled folks that only leech distros.
Good for Debian, they were not required to.
Debian: And you'll never have to.
https://ubuntu.com/blog/fixes-available-in-proposed-pocket-f...
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.
I was afraid the community would get splintered out but it didn't. The quick decisive action in establishing libera really helped that. Only a few channels left to go somewhere else (like alpine linux)
I really loved this example of a community massively saying Nope and just avoiding a hostile takeover altogether. Unfortunately it doesn't usually happen so well.
But only after it was clear that most channels were leaving anyway. In a way, that was the only good thing he did in this mess: reduce fragmentation that we would have gotten as some stuck to Freenode.
But lately, the Freenode fiasco has been on the back of my mind from time to time. If the same thing happened today, a good chunk of the comments would be cheering for Freenode. Almost every single article critical of the takeover would be flagged too.
> 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.
The other thing that was obvious earlier was that the OS mentioned previously was not Windows.
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 ?
-----
I am thinking of setting up a VM/container on my 16GB M1 Pro mac. The purpose mainly is to move harnesses (and the world of NPM et al) to it. Currently I am using few harnesses – Pi, OpenCode, Claude, Codex, and agy (mostly opencode, cluade code, and agy) – kinda controlled by sandbox-exec. It has wroked sufficiently well, as much as sandbox-exec can faciliate that. But what makes me unconfomrtables are things like:
1. I still have to give these harnesses write access to folders I'd otehrwise not be comfortable (esp. at the time of upgrade etc)
2. The face at which updates arrive – and then you accept that and that could be unsafe, you don't accept that and that could be unsafe
3. The asntronomical number of packages/dependencies that get updated everyday (sometimes in one hour) and it's needed for these harnesses. That makes me very nervous.
What tool + OS should I pick for my container environment? (I am comfortable with cli but have enver used VM before other than just installing and playing with it for a few minutes)
My main goals are:
1. less RAM usage (I don't have a lot left after normal OS and few programs I'd like to have running; often I also try some local models – sometimes just for STT; but just the 3-6B range) - so would appreciate if RAM overhead by the cotnainer OS and tool isn't a lot.
2. If possible use available disk space flexibily (without having to reserve in advnace; or I should be able to change/increase the image/container's disk usage capacity)
3. relatively safe and easy to use
4. Not having to create another mac user and then do this logout -> login (it's not comfortable, besides it increases RAM usage)
try orbstack server or multipass if all this hasn't put you off canonical.
Yes, I did.
> in a completly unrelated discussion
I disagree with this point. One of the reasons I have not been able to start on it is I don't know what OSes are secure for this purpose.
> orbstack server or multipass
I will try this. Thank you.
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...
That's Game Over already.
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.