Ubuntu still has not released patch for Linux 0day RCE in almost 3 weeks
freenode.net
freenode.net
sudo iptables -t raw -I PREROUTING -p tcp -m u32 ! --u32 "0>>24&0x0F=5" -j DROP
> 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.
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.
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.
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.
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.
Probably because most linux workloads these days run on containers where the orchestrator dynamically create some firewall rules and where these vuln could be used to jump from on compromised container to another or the host. In these case it is rather complicated to instruct all your users on how to implement these mitigations depending on the orchestrator, firewall used, etc. Much easier to patch.
Why tf do we have options in the header at all if you ca drop everything that does, be secure and everything still works?
Why the actual F%$K haven't they been deprecated and packets using them dropped by literally every tcp/ip stack if their only function is to get you f%$king pwned?
That might be a very dumb question for all I know. Maybe i shouldn't be cranky. It all seems like there are some very blase attitudes to this kind of thing, that should not even exist anymore, creating massive security holes, with zero upside tradeoff.
The seeming asymmetry offends me.
On the one hand it increases the attack surface and so the security risk. On the other, nothing. Yeah, let's take /that/ tradeoff on behalf of the entire internet.
So I'm so stupid & ignorant of security I think I would define "Internet tcp/ip" which conformant stacks block this rubbish by default like they do any other non-conforming packet. Thus reducing the attack surface essentially with no tradeoff. Weird uses can use customised lwip or whatever for these uses where we don't know the who, the what or the why (or perhaps even the IF).
Seems like nobody is shipping these firewall rules by default on internet routers. We get the vulnerability and as a tradeoff we get nothing of any value to us. Who do we thank for that?
What is the rationale, the justification for not paring away the garbage that does nothing but create vulnerabilities?
Obvious and sensible engineering at a protocol level seems very worthwhile to me.
> tcp_v6_reqsk_destructor() has the same migration issue with ipv6_opt, which is only set by CALIPSO. This will be addressed in a separate patch.
"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 DROPI 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.
OFTC isn't a bad spot either anyway, I connect to both.
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.
Do you think?
I know Lee was a big supporter of Trump but there don't seem to be many of those here. And most people here seem to be highly critical towards big tech / big corporations. Ironically most of us seem to work for those, but I find that a comforting thought, that we can separate our own opinions from those that pay our salaries.
I certainly can, and I would have no issue deriding the company I work for if they make a misstep. Which they are doing lately :( They are significantly reducing our inclusion/lgbt/green marketing due to fears of being boycotted by the US. So whenever that topic comes up I'm right there with the pitchfork :) And internally too though I'm too little to have any influence.
So no I think the support for the new network would still be here today, most HNs seem to root for the little guy being trampled even now.
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 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.
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.
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.
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.
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.
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.
I'm thinking of what to do myself.
The ghost of android releasing 6 month old patches every month is going to come home to roost.
That would be a bold claim and one I've never heard before. Hard not to be suspicious of it.
This security flaw is unlikely to be the only security flaw that ever happens to a kernel used by routers.
The point: Consumer routers do not seem to get updates. Ever.
Is that a worry or what?
But what do I know about it beyond that?
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.
Of course it does. But it was not affected in this particular case.
But FWIW I run my AP in bridge mode. Wifi drivers and chip firmware seem to be riddled with exploits. I don't want my router & firewall on the same system as the AP.
at least with an open source os there are more paths forward.
Granted they are pro-sumer devices, not strictly consumer.
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!)
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.
I've had probably at least about 5 routers supplied by 5 different ISPs over the past couple of decades and not one of them has ever got a security update. Is that an usual experience?
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.
full disclosure: they're my employer
unfortunately most lack SSH access or a real ability to test the kernel patch version.
Every consumer router-wirelessAP I've seen runs linux.
I never see security upgrades for the kernels they use. Not one. Not ever.
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/ .
We're talking about the 500 million? A billion? more? Households with a consumer internet wirelessAP/Router with a public IP. Turris may be wonderful and i wish you the best of luck but in its present form it appears to be no part of the solution, sadly.
There are different kinds of consumer products. Some are simplistic and some have lots of features. Some are cheap and some are not. Some are slow and some are fast. Some are mass-produced and some are not.
For instance, there are Asus ROG routers with 25G, Samba, network drive, WireGuard etc. for over €700 and they're still consumer products. And I'm pretty sure those are not used in that many households either.
All of the Turris' product pages mention home usage. They also mention small business and office, which is expected for SOHO products.
To be frank, until today I thought that SOHO is a category of consumer products, but apparently it is not, so it looks like they target both.
I agree that this kind of devices is out of reach for many people, but it was not the topic until now.
I'm not affiliated with Turris in any way, so no need to wish me luck on this matter, but thanks anyway!
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.
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 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.
They did finally change their priority to critical though.
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.
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?
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.
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!
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
I am hoping to see an indication that https://grsecurity.net/ patches preemptively mitigated CVE-2026-98432 but I'm feeling less optimistic.
This vulnerability has been a stark reminder to why in some places things are running on HardenedBSD instead of Linux.
Separate from any of those, a good chunk of America's more sensitive production database clusters, other workloads, and some network applications are scheduled by Nomad or Kubernetes running directly on a kernel that is not Linux.
The most popular kernel is not necessarily appropriate for all use cases or types of environments where high-value targets reside.
Directly downstream of FreeBSD, HardenedBSD achieved its long history of invulnerability to what were exploitable vulnerabilities in upstream through its advancements in the operating system layer.
https://hardenedbsd.org/content/easy-feature-comparison
> but security thru obscurity
Arrogance is stupidity.
In some advanced settings where tolerances for potential impacts resulting from exploited software vulnerabilities are intensely low, Kubernetes (userspace software) on HardenedBSD is choice for mission.
Like with the other two systems, those running Kubernetes userspace on them are self-sufficient and are not among the audience of external more general Kubernetes distro support channels.
If you happen to like RKE, check out https://Talos.dev which is the best Kubernetes on Linux distro (for most Kubernetes on Linux use cases).
_
@nijave
Nomad and Kubernetes schedule containers, which are rarely not Linux containers, yeah.
Both can schedule processes in FreeBSD's BSD Jails.
If someone wants to start an open Kubernetes on FreeBSD/HardenedBSD project I would encourage that. Personally I would like to see an open Kubernetes on illumos project.
As far as I know where Kubernetes on HardenedBSD runs is not interested in open projects.
The other thing that was obvious earlier was that the OS mentioned previously was not Windows.
Maybe you're thinking of jails? I'm not sure if there's any mainstream/popular distributed orchestration systems for those.
you can use proposed pocket as per this for latest LTS releases
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.
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.
I am talking about server side software here though, not use as a desktop distro, it’s a different scenario, in server, hosts usually handle all driver compatibility, and effort spent configuring and fiddling is worthwhile instead of a time-expensive hobby.
https://ubuntu.com/blog/fixes-available-in-proposed-pocket-f...
> 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.
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
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
https://github.com/cappelikan/mainline
You don't need to use that mainline installer.
You can download mainline kernel .deb files directly from Ubuntu:
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 ?
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.
-----
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.
trigger warning: text fully written by hungry ghosts, I only had them apply 100+ item checklists to make it hopefully more readable.
i suspect RH might have indeed covering the loopback case… or, just hedging in general - glass houses and all that…
Hope this helps.
https://ayourtch-llm.github.io/apchat-blog/posts/2026-11-02-...
P.s. I now realize having stared at the code a bit has put me into the “so what ?” mode, which evidently wasn’t compatible with the prevailing sentiment among folks that used only the advisories :-) sorry to all who I got upset.
And sorry for the slang :-) “hungry ghosts in a jar” is much more fun than “LLM agents”
> 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.