Worse yet, the Ubuntu security incident page[0] lists "Ubuntu Priority: High" (as opposed to Critical, which would trigger an out-of-schedule patch). There's a "Why this priority?" link that simply says:
> Why is this CVE high priority?
> See ubuntu cvss score
That's it, we don't even get a period on this TBD of a sentence. It's followed by a generic link that explains what "Ubuntu Priority" is, but that page contradicts their choice. Note that it doesn't offer any mitigations either, and even the (horrendously unclear) description is copied from the NIST page, so there's no actual message from Ubuntu.
I already had a bad feeling the first time I saw "Get more security updates through Ubuntu Pro" on `apt upgrade`, this is now the kick I needed to move to a different distro.
I don't think this is fair. They don't do a good job of pointing you at their rationale which is in their security score here[0]. I ultimately had to have claude translate the kernelese in to something my small brain could understand but this is a bug that could crash your system but is unlikely to expose your confidential system data to attackers or degrade data on the system. Especially given that the exploit can only be done if packets with IP options. IP options are commonly dropped or removed from packets on the open web. You not only need a vulnerable system but a vulnerable request path through the internet which you would only know by trying this attack which is very timing dependent with the SYN,Retransmitted SYN and Reset all happening very close together. A motivated attacker could probably do this on your network but over the internet ... It sounds unlikely.
> this is a bug that could crash your system but is unlikely to expose your confidential system data to attackers or degrade data on the system
Red Hat disagrees[0][1]. They might be parroting Anthropic, and Anthropic might be exagerating the impact (likely!), but that's the current consensus about the vulnerability. If Ubuntu disagrees, they should have said something and not pasted "Cvss 3 Severity Score 9.8 · Critical" at the top of the page.
> A motivated attacker could probably do this on your network
I find that's still catastrophic given how centralized cloud environments are.
> I find that's still catastrophic given how centralized cloud environments are.
It's not like every cloud environment is vulnerable. GCP drops these options for example.
> If Ubuntu disagrees, they should have said something and not pasted "Cvss 3 Severity Score 9.8 · Critical" at the top of the page.
Again I'm going not going to argue they did a good job at pointing at their rationale but it looks like 9.8 is from CVSS 3.0 and they did prioritization with 4.0 which is 8.3. They definitely should have put that up front.
That would still be an RCE in the default install under certain circumstances, and the security advisory has no legible description or mitigations for an issue that other vendors have patched two weeks ago.
I would be perfectly ok if they had either quietly patched it earlier (like Debian), or communicated their prioritization, or they inexplicably delayed it but provided a high quality advisory (like Red Hat).
I don't like complaining about my fellow security engineers, but this one was real bad and is still personally affecting me.
> If Ubuntu disagrees, they should have said something
Exactly. There's room for considered differences of opinion, but that consideration requires discorse and explanation! The lack of communication here is just absolutely baffling. It's like they're deliberately trying to trash their own brand.
I mean, seriously what's going on? We know they have a process for emergency kernel updates, because of course they do. If they're not going to pull the trigger on this particular one (that everyone else is pulling the trigger on) at least make the case.
Greg Kroah-Hartman the long-time Linux kernel maintainer (USB, PCI, driver core, sysfs, and -stable releases) gave a talk on LLM assisted CVE discoveries. In that talk, he downplayed those exposed CVEs from Mythos. What you described above matches his sentiment on downgrade those CVE vuln score.
See previous discussion and the actual talk on YouTube:
> but this is a bug that could crash your system but is unlikely to expose your confidential system data to attackers
Given people have demonstrated getting root with it, unlikely seems questionable
> Especially given that the exploit can only be done if packets with IP options. IP options are commonly dropped or removed from packets on the open web.
It sounds like iphones use mptcp in the wild, which use tcp options, so im not sure how true this is.
> It sounds like iphones use mptcp in the wild, which use tcp options, so im not sure how true this is.
There's so much commentary misunderstanding what ip-options are that I find it difficult to make any judgement call. I do know that I've got routers on 5 continents with hundreds of public IPs and none have triggered an IP packet with an ip-option arriving on the WAN side, or seen on the internal side other than ones I've created with scapy trying to reproduce this. I also can't get these packets to traverse any internet paths I've tried.
IP options are annoying in big fast routers because they have to take the slow route via CPU. As there's not
a lot of use in accepting packets (externally at least) with IP options, they tend to be dropped totally (but will almost certainly be policed aggressively to the CPU as the CPU is not good for moving many packets).
Anthropic claims they have and they havn't been caught in a lie about this sort of thing yet. From a theoretical perspective, if a memory safety vulnerability in kernel network stack is exploitable, then root access would be the endgame so it fits.
Asked claude/haiku5.5 to review that cve against my server, docker images. Claude had passwordless ssh access to that server and no root access. It did the review, confirm that server has the volubility, asked me to ran a few sudo commands, give it the output. It asked me to run a command to disable mptcp option.
I then asked it to do complete cve reviews on the host server (U 26.04 was installed a few weeks back) and docker images on that server and update the security review and added a task to do daily check on ubuntu website on kernel security update.
EDIT: Just asked claude if it can write a patch and build a image on top and fixed the issue on my server. It said it can. And point out that it can apply the 2 lines patches https://github.com/torvalds/linux/commit/e3f33b0.patch and build a kernel image on this issue for me. FYI....
A problem, at least for me at work, is this has to be communicated to the people who make the decision around whether something can continue operating or has to be taken offline until fixed. So far, said people are not particularly interested in the details of CVEs, just if it's critical and has an exploit available. Which is fair I guess, they're absorbing the risk. I would like Canonical to go a bit faster which would make my life easier.
Yeah, their lack of a satisfactory response is the final nail in their coffin. This incident escalates my consulting advice about Ubuntu from “not recommended” to “switch immediately”.
Some of my clients may be surprised by this change, as I once advocated for Ubuntu as a good choice for a development and deployment platform. While that has not been true for quite a while, they have now jumped the shark into eel-infested waters; I cannot take them seriously any longer.
Not always. Notably, if you have compliance requirements like needing FIPS encryption (say because you have government customers), or that requires you to use a commercial vendor, debian won't work. And if you need more up to date system packages, or a reliable release cadence, Ubuntu might be better.
On desktop, if you need proprietary drivers, Ubuntu is easier to set up.
But yes, if debian works for you, I wouldn't use Ubuntu.
I had to deal with FIPS once because the company I worked for shipped a custom Linux distribution with the product and we had to essentially shoe-horn in some Red Hat OpenSSL packages to get it to meet FIPS requirements. What's funny is that after the customer enabled FIPS, administration became much harder, and the encryption strength was strictly worse.
Anyway, needing FIPS is something of a niche requirement. Debian or Rocky are very sane choices as a default Linux distribution for general-purpose servers until you run up against special requirements.
It isn't a validated build. It works the same, but it isn't sufficient if you actually need a validated FIPS module.
> It's just the library, nothing special about the OS.
If you need validation, then the kernel also need to be validated.
Now, it isn't impossible to get a FIPS validated system working with Debian, but you will probably need to contract with another commercial provider like WolfSSL to get validated components. Or compile things yourself. But that is more complicated and involved than just paying for an OS that is validated off the shelf from Ubuntu, Red Hat, or Suse.
Companies who care about whether their FIPS implementation is validated or not would probably prefer buying from a company who sells it over relying on a guy at their company to get cmake back on track regularly. At that point, it's not just about the module, it's about custody, liability, etc.
Jeez laweez. Since when can lawyers make good technical decisions?
I saw a PIN terminal reboot a while ago and the openSSL version was ancient, pretty much historic at that point. But it has an unbroken seal on it, so it's safe, right?
It isn't just compiling something that works. You need to compile it exactly as specified. And document the entire process so you can prove to an auditor that you did everything correctly. Oh, and there's a list of tested platforms, and if your platform isn't on there, which Debian probably isn't, you need to explain to the auditor why it's ok, and why it isn't reasonable for you to use one of the platforms it was tested on.
What you are paying for is not saving the time of a developer compiling something. It's reducing the friction when you go through an audit.
I wonder what the specifics of certification are. No certificate can ever prove a given binary works correctly. No one really understands how computers work, but here's a piece of paper that says Oracle Linux 11.0 is okay. It was expensive and it has a seal of approval on it, so that proves it.
It doesn't have much to do with this CVE, but if you're trying to sell to the US government, it will often be a requirement, which means that a company making money from those sales will not easily be able to move to a distro without that certification.
It's about using a certified cryptography implementation. Presumably RHEL has such a certification, while Debian has a compliant but uncertified implementation.
This isn't relevant to the CVE, but counters the claim that Debian is always a suitable choice of distribution.
I planned to install Debian in 2009 and in 2014 but the installer was too hard to use, the desktop in 2009 was ugly (maybe in 2014 too), I could not get a running system that I could use to work. Fast forward to Debian 10, same laptop from 2014, and I got a desktop identical to Ubuntu GNOME.
Debian for hosting anything, Fedora for development desktop.
That's been my rule for years at this point, I think I switched back to debian everywhere after the netplan changeover in ubuntu so somewhere around 17-18 (not against it in principle, just the way they did it in practice).
The general advice I've been seeing the past ~8 years is "There is no reason to pick Ubuntu over Debian". I don't know who the opposite advice comes from and why anyone would pick ubuntu for a server.
15-20 years ago the joke was that Ubuntu is a Zulu word that, roughly translated, means "I don't know how to configure Debian". Ubuntu was one of the first distros that allowed one to easily download proprietary WLAN drivers without dealing with the terminal, ndiswrapper, or compiling half-broken OSS implementations; for this reason it caught fire with those who wanted to try Linux but were otherwise unwilling to engage in such shenanigans. I tried it on a laptop around this time and was quite impressed. This reputation for "it just works" has carried them ever since even though other distros now do largely the same thing ( cheap, obscure, or recently-released hardware excepted).
I took the lazy Mint route with my most recent machine since I wanted to use it for light gaming with minimal fuss. I'm going to redo it with Nix sometime soon because the value prop simply isn't there and I'd like to try a declaratively-configured distro.
I recently installed NixOS on my thinkpad z16. I set up a sandboxed pi agent to help me configure it and I think it works great. (I also read enough documentation to understand the nix language).
I hade some issues with the trackpad (worse issues that it not being an apple trackpad ie). I told the agent about the problem. It inspected the config, wrote some scripts for me to run outside the sandbox that listened to the trackpad while I used in as per some instructions, and then proceeded to add a few configuration lines that solved to problem. I was pretty impressed (though I think there were maybe 3 back-and-forths with scripts to run, tbh).
More like 20. If I remember it right, by 2007 the Debian community was angry discussing the installation team's decision to include non-free packages in the installation media, what ended the problem of needing a wired connection during the install.
> Ubuntu was one of the first distros that allowed one to easily download proprietary WLAN drivers without dealing with the terminal, ndiswrapper, or compiling half-broken OSS implementations
None of which was a good reason to use it on servers. Even if you were familiar with Ubuntu there is very little difference between an Ubuntu server and a Debian one.
> None of which was a good reason to use it on servers. Even if you were familiar with Ubuntu there is very little difference between an Ubuntu server and a Debian one.
Something to keep in mind is that the term "server" covers a wide range from datacenter beasts pulling kilowatts per node to old desktops running headless to Pi Zeroes and repurposed cell phones, and some of those use cases do in fact benefit from access to proprietary drivers and even hacks like NDISWrapper.
Beyond that, I've seen two main reasons to use Ubuntu Server over Debian, and I say this as someone who has administered Ubuntu, Debian, and CentOS systems for years and always chooses Ubuntu or Debian when the options are open.
1. For a while there were commercial software vendors that would release Linux versions only for specific distros, and Ubuntu was on that list a lot more often than Debian, so if you liked Debian-style packaging and wanted to use commercial software there was a reason to use Ubuntu. Zimbra was one of those when I last used it in the late '00s.
2. There was a time where it seemed like every F/OSS project had a PPA which made it really convenient to install on Ubuntu with automatic updates as part of the system package manager while Debian had to manually load .debs or might not have even had a package due to older system libraries. For personal toy servers and "pet" dev servers this is wonderful, obviously far less important for well-managed "cattle" servers.
Docker, Flatpack, and to a much lesser extent Snap have pretty much eliminated these reasons though. My home server is still Ubuntu LTS because it's easier than changing it but when it next gets rebuilt things will be changing a lot. All of my work servers are migrating to Debian, we have one Ubuntu instance remaining that just had its last major service switched away and a bunch of CentOS systems on sites which are getting swapped out whenever our techs happen to visit.
I wonder how much Raspberry Pi's choice to use Debian as the basis for their default distribution helped here, because it certainly increased the demand for plain Debian packaging of software that was previously packaged for Ubuntu.
Same for servers. 22 years ago you could install Debian, take it offline while you follow the "Securing Debian Manual" to disable NIS and maybe disallow SSH password logins.
Or you could install Ubuntu which wanted to be secure by default. No open ports in the default install, no shared root password, etc.
Nowadays most of this is common place for distros.
I advocated for Ubuntu for years because it was easier to install and had excellent hardware support. For 2026 I have switched back to Debian because Ubuntu has been making my life more difficult. Ubuntu 26 basically forces you onto Wayland even though it breaks some of my use cases, particularly with screen recording. It turns everything into Snaps which is a hassle because it means I need to mirror both the regular repo and the snaps to my closed network instead of just the repo.
Ubuntu still has the superior installer by a good margin, but it does sometimes like to crash when run offline. Debian's installer at least has the option to go text only. There is also more work to do after the install is finished on Debian, but since that's a script it's not such a big deal.
The one bit of the Debian installer I dislike the most is how if you aren't online when you do the install you get a completely empty sources.list, and the Debian sources are a lot more complicated than Ubuntu's. Debian's support for third party drivers like nVidia graphics is also more complicated and confusing than Ubuntu's.
Enterprises love paying for support contracts. If you have one, you can demonstrate something has been accounted for. A secure software without support is worse from an audit perspective than a security disaster with proper paperwork.
Most of these people never actually involve support they paid for ever.
They can pay for Debian support! (I’m not 100% sure who they should go to, but e.g. Freexian are doing Extended LTS for Debian [1], so I suppose they could do a regular support contract as well?)
> Most of these people never actually involve support they paid for ever.
I've only been in an involved role at one enterprise large enough to pay for support contracts like these, but that one had no trouble getting vendors onto the WebEx while troubleshooting things even if it wasn't clear yet that it was the vendor's fault.
(In fact, they were paying enough that the vendors would actually just hop in to help out with the internal configuration. The most we ever heard were grumblings that we used too high of a priority level on the tickets, but even then, the sentiment from the managers was generally "we're paying for it, and we'll handle those complaints, so do what you need to do to get them on the line.")
But by definition it wasn't a bad choice (or a mistake) if it seemed like the right choice given the information available at the time. Unless you have some sort of crystal ball the rest of us don't.
A choice that turned out badly after reflection of hindsight was not in fact good. At best, it was ignorant; at worst, negligent. Regardless, unavoidable; as you surmise, no one has a crystal ball.
I deployed Ubuntu on a LOT of servers 10 years ago because at the time, they had a track record of doing good things in, with, and for, the Linux and open source community. I had already been using it on the desktop for a long time by that point and knew it well. Ubuntu was far and away the most popular; it was a very safe and sane choice.
That changed when they started heavily promoting Snaps as the next big thing and started putting features and updates behind their enterprise offerings. Basically, they stopped being "Debian, but better." And Debian also made lots of incremental improvements in user-friendliness in that time. Basically, Debian is now pretty much what Ubuntu always promised to be.
Platform support. Oracle Cloud for example only provides images[1] for Oracle Linux, RHEL, Ubuntu, and Windows Server. Anything else you have to bring your own.
If I try to create a new instance on Oracle Cloud, these are the options: Oracle Linux, Ubuntu, RHEL, (CentOS), Windows Server, AlmaLinux, Rocky Linux.
Anyway you are right, I would have switched already if Debian was available. I guess AlmaLinux could be an option to consider, since I've read in another comment that they've patched ahead of upstream for several vulnerabilities this year.
For x86_64, It's relatively easy-ish to upload your own Debian image, from Debian's generic cloud QCOW2 image, and it works just fine. I think ARM needs a bit more work if I remember correctly.
This. For llama-cpp and stable-diffusion-cpp, you get official builds only for Ubuntu 24.04 LTS and Win and MacOS. If you want to run ROCm, support is available in the form of an irreversible install script that wrecks any amdgpu driver install and requires run level 3 ie. without GUI. Good luck with running that on anything other than the exact Ubuntu release it was created for.
The only recent reason I’ve managed to come up with is it far and away has the best support for Nvidia’s various drivers and utilities for running GPUs and its assorted ecosystem, like Infiniband and Spectrum-X Ethernet.
If there’s another option I’m unaware of, I’d love to hear it. Also to be fair, I didn’t evaluate Sid for this, only Stable.
Certain AMD graphics drivers require specific Ubuntu releases and versions. I guess one might reasonably ask "why would you run AMD graphics drivers?" to which I don't really have a good answer. But that's why I run an Ubuntu box ;p. I'd so much rather be running Alpine.
I've set up a new server literally couple weeks ago on a droplet on Digital Ocean - Ubuntu LTS is the default choice(you can select other distros but Ubuntu is the default). So I guess I picked Ubuntu because I haven't done Linux admin in over a decade and it's presented as the default choice by a big cloud provider.
The more I look at this the angrier I get. This is a CVE that Anthropic claims can get a Remote Code Execution on vulnerable systems, which includes default Ubuntu installs running any sort of Go server like Caddy. Bad enough that I shut down my personal website and self-hosted tools (sorry for any typos, my grammar checker is also down).
And this is how Ubuntu describes the vulnerability to sysadmins:
In the Linux kernel, the following vulnerability has been resolved:
ipv4: free inet_opt and ireq_opt after an RCU grace period
tcp_v4_syn_recv_sock() transfers ownership of ireq->ireq_opt to the
child socket (newinet->inet_opt) without copying it.
Another cpu can concurrently process a retransmitted SYN for the same
request socket, and send a SYNACK from tcp_check_req().
tcp_v4_send_synack() and inet_csk_route_req() read ireq->ireq_opt
under rcu_read_lock() only, and ip_build_and_send_pkt() and
ip_options_build() then read opt->optlen twice.
Note that the SYNACK timer itself is not an issue: it holds a
reference on its request socket, and inet_csk_reqsk_queue_drop()
calls timer_delete_sync() before the child can be freed.
Since commit 079096f103fa (“tcp/dccp: install syn_recv requests
into ehash table”), request sockets are processed without holding
the listener lock, so nothing prevents the child socket from being
freed while the SYNACK is still being built. TCP child sockets do
not have SOCK_RCU_FREE, and inet_sock_destruct() frees inet_opt
with a plain kfree(), leading to a use-after-free in
ip_options_build().
A similar issue exists with request socket migration
(net.ipv4.tcp_migrate_req=1, or a BPF_SK_REUSEPORT_SELECT_OR_MIGRATE
program). reqsk_timer_handler() clones the request socket with
inet_reqsk_clone(), so that the old request socket and its clone
share the same ireq_opt, then reqsk_migrate_reset() clears the
pointer in the old one. Another cpu holding a reference on the old
request socket can still be using these options (sending a SYNACK,
or creating a child in tcp_v4_syn_recv_sock()) when the clone is
freed, and tcp_v4_reqsk_destructor() also uses a plain kfree().
Readers already use RCU, and other paths replacing inet_opt
(do_ip_setsockopt(), cipso_v4_sock_setattr()...) already use
kfree_rcu(). Use kfree_rcu() in inet_sock_destruct() and
tcp_v4_reqsk_destructor() as well.
IPv6 is not affected by the first issue, because tcp_v6_syn_recv_sock()
duplicates the options. 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.
How is this in any way, shape, or form acceptable two weeks after the CVE was published?
sorry for any typos, my grammar checker is also down
I assume this is unrelated to the Ubuntu situation, but how does a grammar checker go down? We've been doing offline grammar checking since computers had 64K of RAM.
Self-hosted LanguageTool server[0] with browser addon. 18 gigabytes of n-gram data plus machine learning models. You can catch tpyos on 64K of RAM, but not any deep grammar mistakes, un-idiomatic phrases, or mistakes in common proper names.
Grammatik ran in 64K of RAM on a Z80 running CP/M. (The binary included a Forth interpreter so there was a lot of straight up code compaction.) So yeah, you could catch a lot of common English-language infelicities in a startlingly resource constrained environment... in 1983. Certainly a lot more than typos.
(The reason I remember this bright and shiny data point is I spent a week or three reverse engineering it and getting access to the inner interpreter; the office staff actually used it, though.)
It's so much worse than this, and there is a staggering amount of misinformation running rampant about this bug.
MPTCP is not a requirement, it can be exploited merely by sending specially crafted TCP packets with (any) IP options set. No special MPTCP support, web servers or any specific software listeners are even necessary at all to trigger it, just send the packets and boom.
I think the reason people assume MPTCP is a requirement is because that's what the PoC used... but MPTCP itself also doesn't even rely solely on IP options.
Ubuntu also does not even list a single mitigation strategy... at least RHEL did.
And like I said, any normal TCP packet that contains IP (not TCP) options can trigger the bug. I cannot emphasize enough how important and absolutely ridiculous this is.
Like the post says, this is big enough to get a massive amount of people to completely stop trusting Ubuntu entirely and jump ship.
Debian (trixie kernel) 6.12.113 was allegedly patched for this bug, but there's also a .115 that's been released in the last few days, upgrade to that and reboot.
For Ubuntu (which I don't use), you'd need a 3rd party updated kernel repo, to use a patched kernel from that.
It's not an instantaneous exploit; it apparently takes a lot of iteration over the network. A lot of cloud network providers are mitigating it by dropping options at the border, but unless you test and confirm that, you should assume it's possible for a motivated-enough attacker to compromise your server.
At least for 26.04, there is a 7.0.0-43 kernel available in the -proposed repos that has the patch. Presumably planned to be made availalbe any month now.
> I already had a bad feeling the first time I saw "Get more security updates through Ubuntu Pro" on `apt upgrade`, this is now the kick I needed to move to a different distro.
To be clear, Ubuntu Pro doesn't have the fix yet either.
Moved to Debian few years back and never looked back. We used Ubuntu for a bunch of clients and unfortunately had to let them know they will have to migrate to Debian or similar. It's such a shame because I really used to love Ubuntu until Canonical started turning slowly into your typical everyday corporate.
As far as I know the only working exploit is working on machine with MultiTCP enabled. Redhat also downgraded the issue to "high" and also did not release a patch yet. I would have preferred a patch but I accept that they know better than me what they are doing.
Why would they take so long anyway and be behind volunteer run projects like debian? Is it something about corporate shenanigans and testing? because afaik in fedora for example firefox is always behind in security updates compared to debian.
This was an old gripe unrelated to today's issue. But your clarification is exactly why it left a bad feeling back then, the message certainly implies that my system is not getting all the security updates it could get.
A friendly reminder that it's either "What does that look like, exactly?" or "How does that look, exactly?" - "how" and "like" don't go together.
As for the way to add it, the full approach should be `add-apt-repository -yp proposed`, then `apt update`, then `apt install -t resolute-proposed linux-generic`
A lot of ESL speakers use it this way ("how does it look like", or "how it looks like"), but it's never grammatically correct to the best of my knowledge.
Updated and rebooted an LTS server today. It was a disaster.
Kubernetes node went to pieces.
Apparmor prevented nginx from doing anything sensible, so the ingress didn't work. Easy fix when you know what's up, not so apparent when starting troubleshooting.
One app invoked tshark in a pod, apparmor denied it.
Those two were the visible ones. Apparmor now also blocks some unix signals that e.g. postgres uses in a few circumstances - leaving latent annoying bugs.
Pod shutdown hangs. Logs indicate 7 more apps affected by the signal "armor".
Your comment should be higher. Most indignant comments here are variants of "Tell me you don't know about CVE triage and Linux kernel releases without telling me you don't know about them". I mean, I also don't know a lot about them, but Canonical's security record has been exemplary in my experience, and I see no solid reason to doubt their process in this instance.
First, if this CVE did truly put every Ubuntu machine on the Internet at risk, we'd know about mass compromises by now, and there haven't been any reports. It means the CVE is not trivially exploited.
Second, the gravity of the CVE dictates the security release cycle. Emergency kernel patches carry risks of their own, and it would be worse to hurry a non-critical patch and crash a part of their massive user base.
Edit: I've been enjoying this comment going up and then into the negatives, what a roller coaster.
You suggest that Canonical has concluded that this issue is not so bad and so it is Ok that they have not released a fix.
Customers and users expect alacrity for CVSS 9.8 CVEs in un-hardenable services like the TCP stack.
Whatever Canonical's security record or process has been for other CVEs does not excuse silence and delay in this case. Canonical, unfortunately, does not get to silently decide such a categorized CVE "is not trivially exploited" without criticism, and likely consequences.
> Your comment should be higher. Most indignant comments here are variants of "Tell me you don't know about CVE triage and Linux kernel releases without telling me you don't know about them".
Ubuntu managed to release the updated 26LTS kernel on October 28, but the other LTSes have been sitting around since 26 or 28, so I'm wondering why they haven't been moved to "security" or "updates" in the several days since.
Especially since their page on it mentions October 15
I'm wondering if the CVE in question is not mentioned because it was embargoed so they did not want to accidentally leak things while the kernel went through the (public?) QA workflow. Perhaps the Changelog will be amended at some point to have the CVE?
It’s okay to have criticism, but at least be constructive about it. This “I demand to speak to the manager” energy should be kept out of open source.
The post gives no details about what this vulnerability is, how critical it is, how it is impacting them personally, how vulnerable their servers are, how they are working around it.
Just a title designed to generate the maximum outrage followed by a few meaningless lines.
> The post gives no details about what this vulnerability is, how critical it is, how it is impacting them personally, how vulnerable their servers are, how they are working around it.
Yes it does? And Ubuntu is selling security subscriptions and doing a poor job of it, These aren't open source volunteers, this is a paid product.
I read the whole post and still don’t have any idea what it is and how severe it is. Ubuntu has not marked it critical. Is there any reason to disagree with that assessment? In an entire post criticizing Ubuntu you’d think they would at least make that case.
They have also not shared why they didn’t patch their kernel directly when updated versions have been available for a couple weeks now. Why wait for Ubuntu at all?
Normally what happens is that the vendors get a chance to evaluate the verification, but that in the public's interest the working exploits don't get distributed.
I think the author probably assumes that after almost 3 weeks of the entire world going ape-shit over this, most people reading their post probably know about it already, or know how to find out more, so they didn't feel the need to elaborate.
> Why wait for Ubuntu at all?
There are many reasons... businesses often cannot go this route. But I don't see why it matters unless you're just trying to attack and discredit this person because you disagree with how they write their articles.
Why are you trying to farm out so much critical thinking to other people for you? It is easy to do a quick web search and find out everything one needs to know.
You are talking about the company side of the issues. We are talking about the specific issue that is concerning our ubuntu servers. What is the security bug, and how can someone exploit it? Where is that written?
I'm not following, I don't believe a kernel patch like this would be limited to security subscribers. Or is your complaint that there's a security subscription program but no patch has been produced yet?
He's not a paying customer, he never paid anything to use Ubuntu. You don't have to pay for security patches when you are using Ubuntu, just like any other distribution. He's a simple user, did you even read the article?
But Ubuntu is not some small distro maintained by unpaid volunteers; they are a corporation that offers paid support. I think it reasonable to be disconcerted when a company that you are paying for security updates is this negligent, especially when other distros have fixed this issue far more expediently.
As a freeloader, I would look at how little benefit there is to paying for support and reconsider my choices. Especially when other, purely community-powered distros are running rings around them.
This is a major failure on Ubuntus part. The constructive feedback they deserve is literally the title of the article.
The post gives enough detail, there is a vulnerability that allows root access on servers on the TCP stack, so literally accessible if you are running any service. There are exploits in the wild. Debian has the patched kernel, Ubuntu does not 2 weeks after the CVE is known.
> how critical it is,
9.8 out of 10 btw.
> how it is impacting them personally,
They are clearly rather upset by the lack of an appropriate response.
> how vulnerable their servers are,
They are literally open to anyone with an AI subscription.
If Ubuntu offers LTS and is catering to business it is very much open to criticism. They can take it or leave it, but anyone is entitled to an opinion about it.
It's a large international corporation with hundreds of millions in revenue from enterprise contracts. There is in fact a manager to speak to and I do in fact demand to speak to them.
> It’s okay to have criticism, but at least be constructive about it.
Nah, if you're dropping the ball after you said you wouldn't and I trusted that, I'm going to get angry and loud when you drop the ball. That's just reality, and Ubuntu isn't some Johnny-come-lately volunteer organization. They're one of the most well-funded Linux organizations in the world.
> The post gives no details about what this vulnerability is
It is a very famous vulnerability that has been all over tech news sites. Sometimes it is ok to assume the audience has the slightest bit of background knowledge about the topic at hand.
Neither the headline nor the writeup itself explains it. The fact that there are 500+ comments on this post and not a single one has explained why exactly this CVE needs to be fixed with urgency tells me that Ubuntu's decision is likely the correct one.
The explanation is everywhere: it can lead to RCE , researchers achieved it with mptcp but nothing prevents attackers finding another mechanism. Yes, it is hard to exploit it outside mptcp but nobody has demonstrated it is impossible, so we should be cautious and tag it as urgent
With Open Source / Free Software we're trying an alternate economic model, shooting to overtake the standard model. We rely on volunteers. It creates an awkward situation where we can't be unappreciative of effort (no matter the quality of output), but we also have to have expectations or this model is just not going to work.
So we should respectfully expect better than this. (With the caveat that Canonical is a business. I'm using Ubuntu Pro for free so I won't be berating them, but I think I paying customers perhaps should be.)
I also think that we should consider a sort of an "SLA" concept. If you say "I got you covered" and you drop the ball, I think I do have a grievance in that I could have chosen another option, and now I have to take the time to adjust. On the other hand sometimes people don't actually say "I got you covered" they say "This is a cool thing I'm working on". So something like an "SLA" could clear that up.
>The post gives no details about what this vulnerability is, how critical it is
what? the literal first paragraph says:
"In case you missed it: CVE-2026-98432 is a critical (CVSS 9.8) bug in the Linux kernel's TCP code. It's been there since 2016, so virtually every Linux server on the planet has it, and it can be hit remotely"
I believe you will have a ton of factual page about that. The purpose of this one is exactly what you criticise: rage. With a small error of margin a justified rage. I believe this was the reason it was chosen for submission: to show the rage.
The whole point of paying for Ubuntu enterprise services is you don't have to worry about all this nonsense. It's one thing if you're using Ubuntu for free, it's another thing when you're paying them for a specific service.
> This “I demand to speak to the manager” energy should be kept out of open source.
This. You are welcome to publish patches and demonstrate how people can fix their own machines out of band with what Ubuntu does. This costs you... 10 minutes with AI help?
While it's easier than ever to complain this year, I'm patching all the things while on a walk or not at my computer, it's great!
Not everyone using Ubuntu is on enterprise support, right?
The entire OS is open source. I've lost count of the number of times in my career when something like this has happened and even with the luxury of enterprise support, we couldn't wait. Just find a fast way to patch until support shows up with an official solution.
Amazing I keep getting downvoted for a comment like this on an OSS Linux distribution that you can fix yourself live in production without someone getting in your way.
Because if we were talking about a real world object, nobody in their right mind would say it is the responsibility of the customer to fix a broken object rather than the manufacturer or the vendor.
To be fair: while critical (9.8) it has an EPSS score of <1% (probability of it being actually used). According to [1], [2], and others, at worst the issue results in a kernel crash or a denial of service. I read the post by Anthropic too, but something just doesn't reconcile there between everyone saying its a DoS, and Anthropic alone claiming RCE. So far the advisories I read state "under specific conditions ... result in a kernel crash" and similar.
As the days pass the probability of it being actually used is increasing. The EPSS score is clearly just an estimate, and according to the nist cve database, attack complexity is low so I would take the EPSS score with a grain of salt.
Something like this is rowhammer. Can it be exploited in a lab setting vs practically in the wild? Is fail2ban + WAF sufficient? How much network traffic is needed to remotely trigger the exploit in the field? How much inside knowledge of the system itself needs to be known?
These go from extreme edge cases to viable approaches over time, so it needs to be patched. I think the really messed up thing is the lack of communication from the Ubuntu team. If they have a rationale either way, that's fine. They may disagree on the severity, identified a problem in the fix, etc, but the lack of transparency is causing a loss of confidence in the team's abilities.
Hi all, representing Canonical's product team here.
We have fixes available for Ubuntu 22.04 LTS and newer in the -proposed pocket which are being tested for stability. These can be applied by users and we published a blog with the details. We sincerely appreciate the feedback and will follow up as soon as we can with more information https://ubuntu.com/blog/fixes-available-in-proposed-pocket-f....
This really needs to be hot fixed and just fast tracked to release. It’s for sure costing Canonical’s image and makes it difficult to continue to consider Ubuntu for serious server deployments going forward.
The fix is available in the -proposed pocket for users who perform their own kernel acceptance tests. Under our unified two-week kernel SRU cycle, in the first week we build and smoke-test kernels and publish them to -proposed. In the second week we run certification and regression tests on Ubuntu Certified hardware. Once that testing completes, the kernels are released to the -updates and -security pockets. We keep this step to avoid regressions, and we think it’s the right balance between speed and reliability.
IMO Three weeks is not a right balance of anything. I don't blame you personally, but taking this long is completely unacceptable. These issues are going to keep happening even more frequently as time goes on, so something needs to change. Your customers are going to start blaming you (even legally) for their systems getting hacked due to your company's negligence.
I will not be using Ubuntu for any future desktops, laptops, servers, containers or anything else.
I knew what this is about before clicking the link. While trying to find remediations for vulnerable systems I was also looking for any kind of "official" statement on literally WTF is going on here from the Ubuntu side, but I haven't been able to find one yet. I guess it has to go through the "hacker news puts enough attention on it for someone to care" phase which we all know so well...
Have companies been compromised because of this vulnerability? Ubuntu has an absolutely massive install base. The lack of notable incidents suggests that 9.8 might not reflect real-world well.
If someone does a v2 let's hope they make sure it's actually exploitable when they set it up so they don't leave hundreds of people with the assumption that the cve is not a big deal when the CTF was just misconfigured and the system got pwned in less than 2 hrs after they fixed it
CVSS in general is not the best proxy for "real world impact". You could have a 10 on a software thats only deployed once and the impact would be tiny. In this case, multipath is not used that much (except by go).
Go is everywhere in server environment. It's absurd to claim that multipath is not used that much. Maybe it's me, but go literally everywhere around me.
Also this vulnerability is not strictly about mptcp, although the exploitability is not clear.
But they have very valid point: a CVE 10.0 with root RCE on twenty internal servers is lower risk than one vulnerable internet-facing server. All need to be patched, but the one on the Internet is your critical risk, the others are medium at worse.
Any go service exposed over the internet for me is through an apache reverse proxy. Does that preserve MCTCP? Probably not, especially on an EL system...
Contrast this with: "The Gift of It's Your Problem Now"
We keep doing this to ourselves. Heads should roll at Ubuntu. Start that process right now? You can't. You see, nobody is directly available to sue. It does seem that nobody ever truly cared about that. The insecure codebase and tech debt shall continue to grow because that is the gift.
I think it's less of a concern over the internet because the kind of packet necessary for the exploit tends to be filtered out, but it's pretty scary as an escalation mechanism from e.g. an end-user device to a core server.
Much like with PHP2Shell, it doesn't need to be utterly trivially exploitable to be a big concern.
Yeah that literally is in "does not compute" territory for me. That page literally opens with "Ubuntu priority
High [..] 9.8 · Critical [..] Publication date 15 October 2026 [..] Last updated 30 October 2026" which is exactly why "WTF Ubuntu" is the right response here.
I don't quite understand this page. I thought the kernel binary was in the `linux-image-` packages in Ubuntu.
For example, I have linux-image-generic installed, description "Generic Linux kernel image
This package will always depend on the latest generic kernel image
available." and then "Depends: linux-image-6.8.0-147-generic, linux-modules-extra-6.8.0-147-generic, linux-firmware, intel-microcode, amd64-microcode"
Why isn't there linux-image or linux-modules-* listed as an affected package?
First I thought it was the source package / binary package distinction, but e.g. linux-image-7.0.0-38-generic says "Source: linux-signed-hwe-7.0", and linux-signed-hwe-7.0 isn't listed as an affected package either.
They could use better communication, but if they arent happy with testing a kernel update for something that hasnt been exploited in the wild a few more days making sure its not going to brick a bunch of servers is probably a good thing.
Canonical still maintains it. If you're just hosting some HTML or even PHP, you have a comfortable amount of time before you need to upgrade, assuming you're a paying customer.
I jest, but we had (HAD) an Ubuntu 18.04 LTS that received the backported patch for PHP2Shell, even if the version wasn't supported officially by PHP.
This is why I insist our developers use the Ubuntu repositories instead the official PHP ones: besides possible instability, PHP doesn't do ancient backports.
Rocky was created by one of CentOS’s founders, so is closer to CentOS’s original vision. It’s also closer to upstream RHEL. Alma is more a minor fork from RHEL than a RHEL clone.
Because you shouldn't have to do mitigations for this level of severity while waiting weeks for OS patch. I did that, but now I'm waiting for patch to unwind my mitigations.
You can also use the following Suricata rule if your network firewall supports it:
`drop ip any any -> any any (msg:"CVE-2026-98432: drop IPv4 packets carrying IP options (IHL > 5)"; ipv4.hdr; bsize:>20; classtype:bad-unknown; sid:1000001; rev:2;)`
All the people working at Canonical have gone through the Canonical hiring process, which is quite possibly the worst in the global industry and I can't imagine anyone competent getting through it.
I think it's just brand, ubuntu was what I knew from using it as a personal desktop and then it's the default/most obvious option for a lot of providers, I think even 10+ years ago AWS EC2 defaulted to it above Debian, digital ocean too I think?
I don't remember why exactly but it was definitely just 'linux VPS = Ubuntu' for a long time. I think they got reputation as being the 'just works' option because they were happier to include some non-free graphics drivers etc where Debian was the more pure option but most end users didn't care
But since they added snap and I started running into issues with trying to install Docker etc a few years ago I default to Debian now and most of the time I don't even know which it is.
> Stable Debian is using Linux 6.12, if your laptop has modern hardware what do you do? Can't use wifi?
And Ubuntu 24.04 LTS is using 6.8.
Ubuntu releases a new version every six months, but an LTS — which is probably what most people run in production — only every two years. Debian releases come out every two years.
So if you only run Ubuntu LTS, the release cadence is the same as Debian.
> I think you're forgetting about Ubuntu 26.04 (LTS) that is using kernel 7.0.
Which only came out a few months ago, and which only recently released its .1, so the do-release-upgrade message only recently appeared for most people.
I'd be interested to know how many folks have changed their current production over to 26TLS in the last six months. I'm guessing not a lot.
So yes, there is a newer LTS, but what is its current market share as compared to 24 TLS (or even 22LTS)?
Ubuntu releases its LTSes in even years, and Debian does its releases in odd years:
This is why Ubuntu also has Hardware Enablement (HWE) kernels[1], which are fully supported on LTS releases. The current Ubuntu 24.04 HWE kernel is 7.0.
That, or just pick the kernel package from unstable or testing. Apt is smart enough that mixing packages from different versions of Debian works just fine.
(I mean nothing is 100% but I've been mixing packages for like 2 decades now and literally can't remember any specific trouble resulting from it.)
> That, or just pick the kernel package from unstable or testing. Apt is smart enough that mixing packages from different versions of Debian works just fine.
While I won't deny that this may often work, I disagree that it's a good idea, and that `apt` being smart is sufficient to guarantee that this works (or keeps working in the future).
Arguably, the backports kernel is the right choice to get a newer kernel on Debian Stable. Indeed, in the past, the backports kernel could take awhile to update, but no more - case in point, `trixie-backports` currently contains `7.2`, same as `unstable`.
I'd be wary of mixing software packages from different releases because their libraries might interact weirdly. But the kernel should be more isolated. Not isolated enough?
Either way backports does sound like the best option, sure.
It's not apt not being smart that can cause troubles when mixing packages from various suites. There's no reason to mix in cases where you can just use backports instead.
Debian testing is way more stable than Ubuntu stable. In Debian's parlance, Testing means "release candidate", actually.
If you want real testing, you should run "unstable". If you're in for fun, try experimental.
Running Testing on my desktops and stable on my servers since forever. None of them broke, none of them created problems.
I don't care Stable running 6.x.x. It gets security updates in less than 24h, and is applied automatically before I wake up, and doesn't ship coreutils with 104CVEs, just because it's Rust.
Debian security team used to offer support for testing, but as the distro grew and attack surface increased, that was dropped. However, security incidents are patched in unstable as well and they float up to testing relatively quickly (for a desktop system, anyway). When things freeze, security updates directly land on testing as a fixup polish.
However, while Testing is "relatively secure", it's never "Server secure". I'd never use testing or testing packages in stable or any server for that matter.
The comment you're replying to makes clear that they're not using it on servers. I do the same thing (testing on my laptop(s), stable on my servers); you just have to commit to keeping track of what's going on and manually patch if you think that it's necessary.
I have to add that for me, testing definitely breaks stuff sometimes. Nothing beyond my ability to fix, though. Nothing beyond anyone's ability now that AI is around.
Testing is the staging area for the new Stable release.
However, one thing that many people don't know is that Testing enters a package freeze every time a new Stable release is to come out. And this freeze can last anywhere between 4 to 7 months. So for that time period, it stops having frequent updates and becomes essentially a stable distro.
It's not 'as supported', sure, but I'll also note that wifi, at least, has worked on pretty much every modern laptop which I have installed Debian upon.
Back in 2005-2008 or so, I think Ubuntu was a genuine breakthrough as a polished desktop version of Linux that set a standard that various other distros, eventually, caught up to. I think Cinnamon and other distros eventually caught up on polish.
They also had credible commitments to long term support that brought people on board. I think that was enough to get them on the map, but personally as a desktop user, I haven't used it in a while, mostly sticking to Debian and Arch.
I think you are right about the branding / reputation. Personally I heard negative things about Canonical and I heard that they just basically follow Debian, so why not use the original? It's been a great experience so far. Perhaps because Debian moved to include proprietary drivers out of the box now it is extremely easy to set up.
Yeah this was the same for me. When I first made the switch to Linux for my dev machine Ubuntu was the distro I was by far the most familiar with so that was just the default choice. Later on after learning more and seeing how Ubuntu progressed I regretted not going straight to Debian.
Here in NL as well. I attribute it to population ageing (babyboom generation), but AFAIK that issue is much less severe in USA than other countries which suffered in WWII. China is going to have the issue severe due to the one child policy. That population is going to get reduced a lot (not taking into account migration).
In my EU country, making an appointment got extra steps asking about one's mental state, namely depression or loneliness. One wonders if this age of social atomization, people (probably mostly those elderly) are making unnecessary appointments just to have someone to talk to.
That may be part of it but my guess is that since patients tend not to proactively mention depression and loneliness to their doctor, the doctor's office wants to know in advance whether they should be referring you to a mental health specialist.
Local minecraft server definitely requires port forwarding at the router... as I've learned to my chagrin that Starlink doesn't support port forwarding... Goodbye self hosted minecraft. Did it for nearly a decade and cannot anymore.
The other day, I sent a friend a link to my project. He asked, “When can I use it?”
I was confused because the project was already available, with detailed setup instructions, an `llms.txt`, and everything else needed to get started.
Then he showed me a screenshot of him asking ChatGPT about it. Apparently, ChatGPT was using some outdated cached information or something, because it gave him a wall of text explaining that the project was still “coming soon” and wasn't ready to use.
If he'd just opened the landing page, he would've seen that the project was already available.
Honestly didn't even know if it was something [genericized, or specific?] like "fedora" or "ZFS" (where there are multiple wrappers of it) so thanks for all the help from everyone.
seriously: I am a bluecollar electrician that has absolutely no clue what I am doing. I have several machines because I constantly >BRICK< OSes...
As I only really learn visually (i.e. I love GUI environments), LLMs have enabled me to (quite dangerously, I might re-enforce) finally explore Linux (from MacOS for ~40 years).
I have tried for a long time (to adopt any Linux) – the fact that an LLM also won't be a sassyb when asking simple questions... is one reason I am so comfortable with my/our future(s).
you aren't exploring anything if you have no idea what you're doing! you're playing pretend while not actually doing or learning anything. what's the point?
> What is Ubuntu offering that Debian doesn't provide?
Surprised how many answers here are on "social" reasons, and ignoring that Ubuntu does provide genuine additions to Debian.
Ubuntu includes additional proprietary drivers to Debian. So there are legitimate hardware cases were Ubuntu will work out the box and Debian won't. I can't speak for how many people need those drivers, and how much of choice is down to defaults/inertia etc.
From hearing interviews with PopOS folk, I think this is also a big reason people choose Ubuntu as a base for a lot of Distros instead of Debian.
Using Ubuntu as a base became popular partly for the hardware support, codecs, ease of installation. Typing this from Linux Mint, which offers both the default Ubuntu based edition, and LMDE (the Debian Edition).
Debian has caught up, but it's been a minute since I've installed it.
to capture the cloud market, you also have to capture the mindshare at the desktop market. Do you think a new Linux distro comes out and people just install it on their servers? They try it out on the desktop first to see if they like it. It's why Fedora exists to get people into RHEL.
Evaluating server distro on a desktop with a potential need for proprietary drivers (that was the point) doesn't seem like a sensible way to test how it behaves on a cloud.
Yes I think people try the new distro for cloud by using it on a cheap cloud. Much cheaper and less time consuming than actually reinstalling a desktop. Unless one wants to build emotional attachment to one or another distro instead of testing & measuring things.
> Precisely, I really don't follow this discussion. Cutting edge drivers is what I want on my gaming PC.
I get the sense that the OP of this particular thread was asking about Ubuntu in general, not just the server. If it was the server, I'd understand it, but Ubuntu on the desktop still makes sense. And yes, Ubuntu is in my gaming laptop.
The traditional answer is that Debian is a bit slower-moving in both the Linux kernel and userland, so people who want current versions of popular software often find that they have to do some extra work in Debian.
A gradually increasing number of popular userland applications have been publishing their own apt repositories however so this is less of a problem now than it used to be.
Over the years though I've found that I much prefer Debian's relative stability and more thoughtful, if slightly plodding, release cadence.
Ubuntu issues a version release every 6 months, and there are updated packages in the interim.
I'm on Kubuntu (home installs) but have been looking to move since Ubuntu went over to Snaps and started breaking everything (MX looks most likely for me). The task of moving the family over is stopping me; I've been using Kubuntu for a very long time now.
And most don't use interim releases. Alan Pope of formerly canonical said multiple times that by their educated estimates LTS releases have something like two orders of magnitude more users, and interim is really testing ground for LTS.
It had issues all the time, and finding solutions required searching online, manually. Time consuming, difficult process. Very un-beginner-friendly.
From the throve of all possible distros, one stood out. Ubuntu. Very popular. Askubuntu Forums (with coffee beans denoting ranks) was the place when, 9/10 times, the answer to your problem could be found.
So when your fedora friend cried trying to get his camera and sound working, you either found the solutions already, or asked for them and got them. Usually the former.
That was the biggest advantage of Ubuntu. Big community and wealth of troubleshooting knowledge already available. And it had the opinion of a beginner friendly system. Which made the community grow and created a large market/userbase for help threads/tutorials.
Add to that, that people are creatures of habit and 'voila - you have a lot of people sticking to Ubuntu just because they never got so pissed at them that they would change their distro.
I think it's improved, but I installed Debian on a laptop recently and the fresh system came up without wifi, which was bewildering because it connected to wifi during the install process. Took me a bunch of troubleshooting to find a rfkill setting buried in the system.
AI: you probably turned on airplane mode
me: I definitely didn't
So I love debian but it's still rough around the edges and I'm not sure I'd recommend non-technical people dive in.
This has been my exact Debian experience since I tried it on Debian 3.1. On every system at least one of network, sound, display, or power management just wouldn't work out of the box even if they did in the installer.
I ended up on Mint because I consistently found that Debian was willing to compromise their philosophy for the live distro installer, but they would never warn you that you were about to reboot into an air gapped system.
The old installer (boot-floppies) was legendarily prickly at the time Ubuntu was introduced, but it's long since been replaced by the much friendlier debian-installer. And the default install images now include non-free firmware by default, so modern wifi, bluetooth, and graphics hardware are fully supported.
To be honest, Debian now tends to be fairly vanilla and boring and it's actually Ubuntu that often ends up being a bit weirder. For example, consider how they treat the Snap packaging system for consumer software, or the rust rewrite of coreutils. Debian provides both as supported options (of course it does, Debian supports pretty much everything!), but Ubuntu pushes them to all users by default.
For me it's just because I've been using Ubuntu full time since 2008 and has served me well my entire career, I think it's fair to say it's the flagship desktop OS that introduced many to Linux.
I feel like we're close to a post-distro era of operating systems though. My ansible playbook customizes so much already it wouldn't take too much more to just start from debian tbh.
Me same. I'm on ubuntu since 16.04 and it's annoying switching, because I'm used to it so much. Definitely switching on Debian, because they're not shipping software through apt anymore (eg. browsers). I'm running that through nix right now, and I don't want to deal with this nonsense.
I was thinking of just going entirely to Nix. The last time I tried it was 2021 (on a dual boot where I also tried Arch cause my colleague was bemoaning my Ubuntu usage). Yeah, it is annoying having to look up how to configure things the Nix way, but it all makes sense and it stems from the fact every application does it 'their way'.
Either way, I just wanted to note you can use APT to include Mozilla's Firefox and Thunderbird repo. That way, you get a .deb from them.
One specific thing I like about Ubuntu: I know a new version gets released every six months (I believe OpenBSD innovated this?) and the version is recognized by date. The LTS is released every two years around april in the even years. Otherwise it is april/october.
> it's annoying switching, because I'm used to it so much
Since you're switching to Debian, could you tell me what you don't understand in Debian that was working fine on Ubuntu for you?
I am not an Ubuntu user, so it's hard for me to know. But I find it very surprising that after 10 years on Ubuntu, it would be "annoying" to switch to Debian.
For me, it's not so much "what does Ubuntu have that Debian doesn't" and more that "just use Ubuntu" has only bitten me twice.
It's 2009 or so and I want to try Linux. "Just try Ubuntu" they say, and I have a good time. I see that many "How to use X on Linux" guides, or FOSS software, often build for only Debian, and sometimes only Ubuntu. This is fine until snaps give me huge problems in 2018, and so I completely stop using Ubuntu desktop.
Now in 2026, I manage three servers (two on Ubuntu), one Raspberry Pi (on Ubuntu), and two Linux desktop installations. I stopped using Ubuntu desktop in 2018 but snaps are less problematic for my server workflows, so now I have three Ubuntu server installs. On my desktops and my one non-Ubuntu server, I find myself sometimes missing Ubuntuland. (These aren't Debian though, so I might just be missing Debianland.)
"Just use Ubuntu" is now something that has bitten me in using servers. Two bites in 17 years is a fantastic track record. But this slow response to a CVE fix has me looking at Debian, and this has shaken my faith in canonical. "Do they pull in upstream security fixes quickly" is one of my first questions for any FOSS I use.
But my servers aren't Nix or IaC or whatever, and so... Taking them down and putting them up would take a lot of time and risk, which are two things I'm not so willing to spend. Maybe it's 10 minutes, or maybe there's a bandaid fix I have from 2023 that I forgot about and would need an hour to re-derive. So, I find myself taking the security gamble instead.
Ubuntu offers a path from free use to paid first party support. For me, that makes it very attractive for a startup or small business that may want to add a support contract later. Ubuntu makes it a lot easier than Red Hat. Paid support for Debian is via third parties. Ubuntu is a solid distro, although I think Debian is a better one if paid support isn't an important feature to have.
Ubuntu has a timeline for how long they will provide updates for a given long term distribution release. I moved over to Ubuntu back when CentOS was converted in to a Fedora type release without a long term commitment to providing security fixes.
This is the big reason that I see a lot of companies using it over Debian.
Five years of guaranteed updates, with an option to pay for another five years ticks the box for accreditors and the like.
The much vaguer Debian policy that a release will be supported for some undetermined period based on how frequently they release, and then get some kind of volunteer-based LTS support for a couple of years after that, and then maybe further through some third-party ELTS program is a much harder sell.
This. I can't believe not a single comments above this one addressed the previsibility Ubuntu offers over Debian. It was even one of its founding reason[0]:
We migrated to Ubuntu from CentOS as well. It was simply because Rocky wasn’t established enough at the time and we haven’t had a reason yet to again look elsewhere. Tho we haven’t also phased out most VMs for containers of some sort.
Install Ubuntu and you get 10-15 years of support of your current software stack.
Install Debian and you get 3-5 years of support.
Ubuntu also invests a lot into their desktop experience while Debian is closer to stock Gnome. That's more of a preference thing, though.
Debian has also traditionally been a pain to use with proprietary software. Nvidia drivers, WiFi firmware, you name it. It got better in the past years but it's hard to shake the bad name.
I disagree, 26.10 has me actually using Gnome and not pulling my hair out for the first time in my life. The Ubuntu extensions to Gnome make it way more usable for me, the theming is attractive and consistent, the installer is better than ever.
It's not perfect but it's a big step up from a Debian ootb desktop (unless you really like vanilla Gnome which, more power to you, but i don't)
Good from an open source perspective, for sure (though they have stopped fighting the good fight as much for practicality), but for a lot of Linux users (namely: companies), that good fight is of no real consequence, unfortunately.
Historically, Debian didn't ship proprietary wireless firmware in the installer (because it was proprietary software, and Debian doesn't do proprietary), so you couldn't install it on most laptops without plugging them into wired Ethernet to download the wireless firmware packages from non-free.
They changed that a few years ago, but plausibly the underlying prioritization of end-user experience is still lower than Ubuntu's degree of user focus.
I still wish Mark would rename his company "Ubuntu". He's a great guy, the company does great work, but I keep getting undeserved credit for it because we wouldn't sell him the domain name.
For some reason I had feeling that Ubuntu more "serious" than Debian. I mean they're asking for money from people. So it's basically Debian with paid services. Can't be worse than Debian and probably is better, maybe they paid some engineer with these money to patch things faster.
That's just some rough reasoning in my head.
Also when you install third-party software, 100% of them will support Ubuntu. That's more about workstation usage, though. But having tested platform matters.
How is the gaming experience on Debian? I'm genuinely asking, not a snark.
I use desktop Ubuntu because it's up to date and it just works for me, and I can play the latest games in it with Steam + Proton. I don't have to tweak it or do any additional downloading of stuff besides the Nvidia drivers (I actually don't remember how I installed them).
Can I do this with Debian, in a no fuss way? (I know this can be done in any distro, that's why I'm stressing "no fuss").
Not bad. Steam/Proton keep themselves updated. If you rely on Wine from the repos, you might be in for a bad time, but Heroic/Lutris/Bottles in Flatpak stay updated. You mentioned Nvidia, but amdgpu has a repo that should keep things reasonably up-to-date: https://instinct.docs.amd.com/projects/amdgpu-docs/en/latest...
For some games like WoW I use Faugus on Ubuntu. It ensures I always run the latest and greatest Proton-Wayland.
But this is the thing I appreciate about Ubuntu. I know my LTS is from 26.04. I know all my software (with specific exceptions) is backported from that. The previous LTS were 24.04, 22.04, etc. With Debian, I won't know these out of my head. Partly cause I am into Ubuntu, but also because it isn't opaque. I mean, I don't remember from which time Potato and Woody were (but I used to run both back in the days). With Ubuntu, I remember (the codenames of Ubuntu I forgot).
Rest of games, Steam handles. I'm hooked on their ecosystem, kind if for a similar reason as Ubuntu (loyally sticked to them). As European I'd prefer a European gaming distribution platform, but Steam is just good and a fair netizen. Linux-friendly, too. I own a Steam Deck, too. Only reason I'd want non-Steam is all these free games I got on GOG/Epic/Amazon, and maybe some good ol' emulation.
Nvidia proprietary drivers are generally pretty old. I did some messing around with the CUDA packages to get recent desktop drivers in order to run some games.
Right? Can I install Debian and have Steam work as well as Ubuntu? Can I install Debian over my Ubuntu (without pain) and keep my dual boot with Windows 10 situation? If yes to both, will consider!
In my experience, Linux distros on older kernels sometimes struggle with modern hardware. Especially with newer devices, features and especially bug fixes take a while to make their way to the distro.
If your infrastructure doesn't use landscape, kernel hot patching, JuJu or similar Canonical technology, or doesn't have its own Snap storefront, there's no need to install Ubuntu. Rest is just momentum.
Debian used to move a bit slow in terms of userspace, and that's true, but for servers, that's a non-issue for the last 20 years or so (from my experience).
On the Desktop side, Fedora and Ubuntu moves faster on the userspace front, but if your system is behind a NAT, and you know what you're doing, Debian Testing is just as good, more stable and it's rolling (except when it's feature freeze, but a stable workhorse is better than a shiny but breaking one).
Debian allows me to sleep well at night, provides guaranteed updates, and works rock solid all-round, so I won't be touching Ubuntu for the foreseeable future. Esp, with controversial choices like uutils, etc.
Look dude, let's get something straight: just because someone didn't jump on command for that one patch you suddenly care about out of the blue, doesn't mean they're LARPing on anything.
If you want to dismiss other people's work like that, have at least some decency to provide a track record beyond "they didn't do what I wanted REEEEEEE!!!!" type response.
I would need to reinstall OS on my laptop and deal with all time-consuming migration stuff for everything that changed and to configure Debian where it is doing weird things
> What is Ubuntu offering that Debian doesn't provide?
This is now trivial with agentic tooling. I recently used a separate laptop and VM over a weekend with an agent to complete a full migration. Cost is hours and a dollar in tokens.
Proprietary drivers, desktop first experience similar to how Mandrake used to be, or SuSE, and the most relevant, in regards to proprietary software on Linux distributions, it tends to be either Ubuntu or Red-Hat.
Speaking as somebody who stayed on it way too long (until 10 years ago, maybe) it was because people constantly told me scare stories about how difficult it was to configure into something usable.
I had to go through the torturous path of Ubuntu -> Mint -> Mint Debian -> Debian. The last step was after I used a Debian live disk to do something and I could see that the stories were nonsense; just something that had adhered to the word Debian in my mind through repetition.
The two worst parts about it were 1) that I had long left Ubuntu on servers and had been using Debian there for years - I was just afraid of the desktop for some reason, and 2) that if I had just listened 15-20 years ago when people told me that FrankenDebians were nothing but problems, I would have never been caught in the net.
I've never been a fan of Ubuntu's business practices, but I'm just generally not into Debian derivatives anymore. If I were to leave Debian, it would be for an entirely different (and philosophically different) distro. I probably make an exception for Devuan, because it's only trying to change one thing (that I think of as the biggest threat to Linux, the final boss evil spawn of RedHat.) Devuan is an escape hatch for when the rugpull happens.
For servers, livepatch, latest ZFS and ZFS-on-root supported ootb, faster release cadence
For desktops, gaming and commercial software support, "it just works" (my fresh install of 26.04 with Wayland, recent WiFi, HDR+VRR, i didn't have to fuss with anything)
For laptops, I've routinely had issues in the past where Fedora or Mint wouldn't work ootb when Ubuntu did.
And then since it's what I'm used to on my server and my desktop, i just use it on my Pis and WSL installs for consistency.
I still try out other distros occasionally and i do run Debian on some specific VMs for various things, but I've just had relatively few issues with Ubuntu, been using it for >10 years, and don't see any reason to switch.
At my company, it’s the pateena of “enterprise”. I came to th company with strong open source bias. The more traditional/conservative IT guys were all about Microsoft and RedHat. When I lobbied hard for some Debian assets, Canonical was the compromise. But I think we’re real close now to seeing the next round of allocations be straight Debian.
> What is Ubuntu offering that Debian doesn't provide?
I'm on an nvidia jetson which comes out of the box with Ubuntu pre-installed (it's slightly more complicated but that's the gist). You can run other OSes but it is a messy experience and you can easily run into problems.
Yes, it is shitty from nvidia that they do it this way. But it is also convenient.
It's just the default target. For backend stuff, you're right that there's really very little true value. But client software just has a lot of complexity. If you run binaries from wherever, they're probably built and tested on Ubuntu first. Like, your vendors won't support distros officially, install scripts and AppImage integrations are going to tend to assume stuff. Driver/runtime integration for things like binary GPU stacks are going to document Ubuntu first. If someone makes an assumption about Python version (a personal peeve -- LOTS of python software ends up lagging the tip, it's not a super compatible ecosystem), it's going to be that you're running Ubuntu LTS version "one before latest", etc...
Are those fatal flaws? No. But lots of people just don't want to deal with it. And there's a market for that.
I can't think of anything I've ever had trouble running on Fedora + containers, with the latter typically for proprietary software that depends on specific or ancient userlands, or simply to avoid cluttering up my base system.
You can't put a driver stack in a container. You can't put container stacks (c.f. Docker, Snap, Steam, Flatpak) in a container. Containers can't by default do oddball hardware access for oddball stuff like flashing firmware for your keyboard or 3D printer. You can't reflash your motherboard BIOS from a container.
The fact that your mental model of running your foreign Ubuntu software is "in containers" tells me you're probably mostly running backend/cloudy stuff. And yeah, that's largely a solved problem thanks to Docker (and for the same reason, "Dockerfile" is now a standard platform that everyone integrates and documents for by default).
Again, it's not like this can't be done from other distros, it's that it's fiddly and the instructions and defaults are all going to be for Ubuntu LTS.
I used Debian on my machines (after I got past their ideological view on drivers and found I could get them separately and made it work) ... until a patch came out and WiFi was broken on my machines. I went back to Ubuntu, have not had issues like that. Ubuntu works reliably, from my experience, on real world machines.
Ubuntu did what Debian failed at. Better LTS, More features including drivers, available by default by most providers, lot more branding/documentation and in the early days, easier distribution. I am old enough to remember distro like SuSe Linux etc and when Ubuntu came on scene, it became the de facto.
Just that it’s already installed, and I haven’t tried a new distro in over a decade.
But 15-20 years ago it was easier to install the nonfree stuff on ubuntu, like drivers and DVD playback and stuff. I don’t know if its still like that.
I never understood ubuntu as a server over debian, but for a desktop it was a nicer experience for a while.
They test run a little more tests on their backports (and have the manpower to actually look into what is failing) and they have really far out EoL once the kernel release is selected at fixed intervals. So if you managed to get the capabilities that you care about in their tests, there is a low probability that applying updates will cause some catastrophic outage or data loss over the next 10 years. Which can be improved further by fine-tuning phased update rollouts.
Unfortunately, they did in recent history manage to still break iptables, zfs, nilfs and a bunch of machines with weird (arguably broken) firmware anyway, so my personal comparison between Debian (or simply directly the Kroah-Hartman/Levin stable upstream) and the Ubuntu backports is not exactly in favor of Ubuntu.
I always assumed the software is newer. You can update to a LTS more often, if your server needs that. For example, I think podman adoption is hampered by Debian's slow release cycle. Trixie finally supports quadlets.
Debian often ends up as Frankendebian, or with custom repos added. How do you run e.g. Nextcloud on Debian? Where do you get the new php version required for the upgrade from? Right, there is a community repo somewhere...
I should mention this is maybe not an issue for servers with containers, nowadays. And desktops have marketplaces and linuxbrew.
But it took 3 years from Debian 3.0 to 3.1, then 'testing' was frozen for 2 years. A lot of users were lost to Ubuntu at that time, which released every 6 month.
Debian by default has had ancient versions of stuff, and if you want third party software, Ubuntu has more mindshare so it was more likely to be tested - anything from graphics card drivers to Steam games.
When a non-technical person asks me “which Linux?” I recommend Ubuntu because it is about as gentle an experience as Linux is going to be. The install is friendly and the culture is less RTFM than anything else.
Those are the same reasons I run Ubuntu on my laptops that aren’t running Windows…I prefer low friction to arguable technical superiority. I’ve looked at other distros in the past and decided they weren’t worth the bother…To Me.
But that’s me, not you or anyone else. And my use case not yours or someone else’s.
Consumer-centric customizations and non-free package options.
It’s somewhat akin to answering “How can I add stuff like OneDrive to Linux and not have to configure/self-host everything?”
I used to like Ubuntu and Canonical products and these days I’m more indifferent towards them. Their products have a place, but I wish Canonical would stop killing off some of the more interesting side projects.
I'm not a Linux user, but occasionally self-host some stuff.
One time I tried Debian instead of Ubuntu, it was a lot of "this is not installed" & "this is not set up" errors during setup process of software I wanted. In the end I succeeded in doing what I wanted, but I also wasted time on doing things I never have to do when using Ubuntu.
But we're talking about running a server in production here.
If one can't be bothered to install what is needed, maybe one should not run a server in production?
Quickly running something on your LAN for testing is different, but if you expose it to the Internet, probably your main concern shouldn't be "this is not installed".
MySQL. You can make a totally valid argument that sites should just switch to Maria DB instead, but there's also no doubt that dropping MySQL support from Debian cost it a lot of LAMP servers. That, combined with Debian's release cadence which made it difficult to run numerous PHP apps basically pushed LAMP servers to Ubuntu.
Familiarity. Many Ubuntu people(who were introduced to Linux via Ubuntu) never change horses. I am speaking about IT people not common folks.
You and I know Debian isn't much different, they don't know cuz some never investigated. I say some because they landed in a role with a company that is Ubuntu and never had reason to learn anything else.
As I understand it, this is based on the Ubuntu LTS kernel, but doesn't necessarily rely on upstream's release schedule for fixes.
Given that most of the Proxmox userland comes from Debian Stable repos directly, it's probably not the worst idea in the world if you want to run ZFS on mostly-Debian Stable.
Oh, and while I'm not sure when the fix was applied, CVE-2026-98432 is patched on my Proxmox (no subscription, all ZFS including root) server.
For desktop use, new-ish user-facing packages without any hoops (such as backports) jumped. Especially where collaboration is involved it can be a major issue when a program lags behind its commercial OS counterparts by several months or years in terms of features and behavior.
I don’t use Ubuntu but use Fedora (and its derivatives) partially for that reason.
>What is keeping people on Ubuntu instead of just using Debian?
1. It uses much newer packages and people want shiny
2. It was marketed as one of the easiest to use linux distributions maybe 15yr ago or whatever, so a lot of new people and then tutorials went to it because newer software and features just worked.
3. What is keeping them on it now? Familiarity. Inertia.
They probably don't know Mint was based on Kubuntu. Or that they all - like DSL, Knoppix and others are all based on Debian and if you're brave, you can pivot to Sid from each of them.
When I worked at Canonical, the funnel I observed was Gamer Culture and the Chronically Online. They don't know from Debian.
I only run Debian personally, but my dayjob company runs on SQL Server, and the officially supported options there are Windows Server, Ubuntu, or RHEL. It's not worth the effort dealing with management/auditors/etc. to try to run our prod DB on a non-supported platform.
Because every where you used to go on the internet you read that debian is “slow” on updates but stable as a trade off, if you are after certain new packages you have to use Ubuntu, also, some use cases (say jetson boards) have ubuntu by default plus nvidia drivers.
Ubuntu is the gateway drug to Debian, in a lot of ways. You get used to GNU/Linux with Ubuntu, then you find out that there are more refined options and go for those, and a not-insignificant part of that crowd likely goes to Debian because of how familiar it is.
I agree btw. But I've been using Linux since end of 90s (I barely made use of the 2.0 Linux kernel series). I quickly established on Debian in the Potato/Woody era. Debian, back then, was severely slow with new releases. So I ended up with Testing. Which got slower security updates than Unstable. Which sometimes broke (like any rolling release does). Back then Ubuntu got released (we talking '04 and '06). And I just sticked with Ubuntu. On servers, too. I endured it all, including the Amazon spyware, the ads in MOTD, and the switch to an inferior in-house software management for some package (which name we won't mention).
I think it's a good opportunity to remind those reading this thread that they need to talk to their children about Arch Linux before someone else does.
I know it seems innocent enough at first, setting up a system just the way you want it and learning a lot of Linux's userland internals while doing so, but before you know it you're installing esoteric window managers to get your theme just right and hunting for the perfect picture of an anime waifu to be your wallpaper, all while telling others that you "use Arch, btw". Always sad to see someone fall into that sort of life.
For me, habit. A habit I'm getting tempted to break by exactly the grumble in this post. This has been an awful ~two weeks for maintaining infrastructure and the ubuntu lag on this specific issue is contributing to the awfulness.
any broadcom networking hardware, on debian it will constantly drop out @10Gbps link speed on copper is one such case that I can describe. But over the years there's been plenty of related issues with e810's and whatnot. Disks, disks will also stall or drop out which doesn't happen on ubuntu kernels.
Enterprise support contracts for Linux and the compliance legal liability. No large commercial companies would run purely contributor supported systems because of the lack of those two things.
It's the default that a bunch of vendors package. For example, Nvidia's official CUDA images used to only be provided for Ubuntu (they have since expanded their offerings somewhat)
Desktop Ubuntu purely because of the drivers. Normally used Debian for my own servers, but haven't done that in so long, and Ubuntu is often default on cloud providers so yeah.
FIPS mode? It's a pretty niche requirement, but I was under the impression that options are somewhat limited for FIPS-compliant crypto (both disk and networking)?
Back when I used Ubuntu it was because I was tired of being excited about a new feature and not getting to use it until it made its way to Debian 5 years later.
Suppose you are an enterprise paying large amount of money to NVidia to buy their AI hardware to run AI workloads locally. Are you going to say we will refuse the default OS (https://docs.nvidia.com/dgx/dgx-os-7-user-guide/introduction...) on such hardware and lose hardware support, or are you going to stick with the supported OS for your hardware?
Enterprises care far more about vendor support than the typical Linux hacker at home.
Approx. two years ago I saw a teacher at my IT school trying to install Debian on a students virtual machine, side by side to a Windows 11. Just for fun, while watching them, I installed Ubuntu side by side on my virtual machine. These two were not done after three sessions and ultimately failed to install Debian. The installation GUI was full of cryptic words I never heard of and looked like from the year 2000. Meanwhile, the Ubuntu installation went flawless. it was done in under 15 minutes, the GUI looked modern and sexy. All I had to do was enter a nick and password, and drag a slider to tell the procedure how much space I want to reserve for Ubuntu.
AFAIK Ubuntu still ships newer versions. Maybe this is just because it ships new distro versions more frequently, but the end result would still be having newer packages on the latest Ubuntu release vs the latest Debian stable. I'm not an user of either distros though, so I'll wait for someone that actually uses them to confirm/rebut.
1. Faster and predictable release cadence. New releases every six months, April and October (hence x.04 and x.10). New LTS releases every April on even years (26.04, 28.04, 30.04, etc).
2. The LTS releases are supported by Canonical for at least five years on the free tier, and up to fifteen years with paid support contracts.
Agreed. Two weeks is pathetic. But, yes, I went over to Ubuntu because they were supposed to provide five years of security updated.
When I interviewed with them a couple of years ago, I got the sense there was a lot broken with their culture. It was the best choice back when RedHat/CentOS stopped providing long term security updates, but now that Rocky Linux is around, it’s getting to be time to jump ship again.
Also, almost every other time I upgrade Ubuntu, it's a shit show. I've seen the renaming of network interfaces, loss of default routes, systemd jobs that take several minutes to timeout... It's like rolling the dice. All the problems were fixable, but still an annoyance.
If it's a corporate computer you don't want to deal with manually configuring stuff. I also want as little manual configuration on my personal machines, hence why I use Ubuntu.
It just has package for nvidia drivers. Not sure if installer will install it automatically for you (I kinda... use my install for last 12 years, just upgrading it).
For me both with AMD and NVIDIA whole hardware driver story was "install it, it works"
I'm referring to the ubuntu-drivers thing. You can do the equivalent in Debian if you add non-free repos and find the right packages, it's just more hassle. But if all you need is GPU drivers, no need for that tool.
At least Debian is on Wayland. Mint is on X11, which was causing black screen out of the box on my fairly typical PC.
I suspect many new users get confused by the fact that lots of Nvidia hardware works poorly out of the box, rather than not at all, where the latter would at least provide a clue that a non-inbox driver might solve the problem.
>Oh and btw, distros run by volunteers (Debian, Arch, Alpine...)
And Slackware too:
Thu Oct 22 23:04:17 UTC 2026
patches/packages/linux-5.15.223/kernel-generic-5.15.223-x86_64-1.txz: Upgraded.
patches/packages/linux-5.15.223/kernel-headers-5.15.223-x86-1.txz: Upgraded.
patches/packages/linux-5.15.223/kernel-huge-5.15.223-x86_64-1.txz: Upgraded.
patches/packages/linux-5.15.223/kernel-modules-5.15.223-x86_64-1.txz: Upgraded.
patches/packages/linux-5.15.223/kernel-source-5.15.223-noarch-1.txz: Upgraded.
This update fixes bugs and security issues, including the PwnEscape flaw.
For more information, see:
https://www.cve.org/CVERecord?id=CVE-2026-99999
(* Security fix *)
Slackware is a cool distribution. I really love that it's maintained by Patrick and I enjoy the simplicity and the stubbornness of it's opinionated decisions.
I stopped using it back in 2004 when Patrick had health problems. It seems to be a passion project and it stopped getting updates while he recovered. There is a community behind it but it may mainly be driven forward by him.
It looks like it's fairly slow to get updates, generally, as the last release was Slackware 15 in 2022. Maybe that reflects it's dictator (his word not mine) or maybe it reflects it's stability.
Yet, despite all that, Slackware got this security fix around 10 days ago.
There's dvd iso's available the slackware-current branch, usually built about once a week by AlienBOB
Guess you could call it a passion project, but after all these years of dedicated tireless work that seem to resemble more of a machine than man, seems that doesn't completely sum it up. Hope he keeps it up, its pretty much the only pure distro left (or maybe I dislike systemd that much)
You get a very different CVSS score depending on the formula you use. Ubuntu's response page lets you select between the two.
(I think CVSS is a very poor metric in cases like these; I'm just explaining what I think Ubuntu's process/position is, not making excuses for them. My read is the 9.8 is probably too high but nevertheless more accurate in this case.)
I moved over to Debian and haven't looked back, years ago. Why anyone would prefer Ubuntu over Debian, which is a purer, higher quality, more mature distro, is beyond me.
Ubuntu (and Kubuntu) have never bricked all of machines after an update, Debian did, in recent years at that. So I will argue quality in favor of Ubuntu (and Kubuntu).
My opinion of the story is that it is over hyped, with my hunch being it's possibly to throw free advertising towards Anthropic, though I have no proof of that, just my personal intuition based on the handwavyness of the story.
My view is based on having used Ubuntu since 2006, Kubuntu since 2023 or so and a serious stint on Debian until they put out a patch via regular updates that bricked my machine's wifi (all of them). So my view is based on real world experience and your comment "Your view does not seem to match reality" doesn't seem to take my experience with Ubuntu and Debian into account.
Well, I did it. This was the straw that broke the camel’s back: I have moved over to Rocky Linux. Took me maybe four hours to do the full transition.
I am more a RedHat user, and Ubuntu never felt really comfortable for me. I don’t like having to do incremental upgrades every two years or so; I would rather do a single big upgrade about once every 7-8 years and have a rock solid development environment. Also, `dnf` is simpler and more stable than the mess of `apt-get` and `unattended-upgrades`.
> Also, `dnf` is simpler and more stable than the mess of `apt-get` and `unattended-upgrades`.
I'm not saying you're wrong. I am saying that this is a new sentiment I've never heard expressed before. Perhaps Ubuntu's done something to make it flaky, but the upstream Debian apt tooling is famously stable and boring. I'm saying this very seriously: I don't recall a single time, ever, in about 30 years of using Debian-and-friends, that I've ever been bitten by a bug in apt-get or apt. I have also never been hit with a dependency bug when I wasn't using dodgy third-party package sources. In the many situations where I've deployed pure Debian (or pure Ubuntu) servers, `apt update && apt upgrade` has worked 100% of the time.
I do not claim that no one's had problems with this. The world's large. I'm certain there are people out there who have nothing but trouble with apt and friends. I do claim that I've never personally seen that our been in a conversation with people who have.
`unattended-upgrades` was frequently giving me Python warnings in Ubuntu 24.04 about how `fork()` should not be called. `apt-get` has given me issues, years ago, where it would pull up a crappy full screen text UI asking me (usually irrelevant) questions about some update it was doing, and the entire update process was halted by those questions.
I have one Ubuntu Pro server and it has not received the fix yet.
Fedora would have been preferable but that is "not supported" and I had to have Ubuntu.
I think this is the important question. To everyone who is complaining while using Ubuntu for free: People whose software you use for free don't owe you anything.
Of course they don't owe them anything. Ubuntu's reputation is built primarily on people who use it (or used to) for free. They are/were Ubuntu's advocates and what made it popular.
So just as they made it popular, they can make it unpopular. People like me will simply post on our blogs and social media that they should not install Ubuntu. A typical Ubuntu user is not that high on the tech scale, and they listen to people like me for suggestions on which distro.
I don't like ads, and I didn't like logging into SSH and seeing a nag to update to Ubuntu Pro because I had the balls to keep running 20.04 in 2023. I've seen this before on previous releases (and know how to remove the message), but seeing it again was the straw the broke the camel's back.
AlmaLinux is "boring" in the best possible way, and it works really well in WSL too. Their extended support for x86-64 v2 has also been useful on one my old computers.
This is the straw that broke the camel's back. I am moving back to Debian stable now. Having NVIDIA drivers and Wlan drivers back in 2014 was great, but this is not acceptable.
I have had some thoughts about switching to Fedora for my daily driver laptop - but as far as I can see I would not be better off in this case with Fedora? I cannot see that they have shipped a fix for this either?
I think this is more of a communications failure than anything. My understanding (happy to be corrected) is:
1. That for this to be a DOS type exploit, the attacker needs to exploit a race condition over network, which is an incredibly unlikely event that one can't really force.
2. For it to be a root exploit they need to craft the IP options with a specific memory address, but that memory address isn't known to the attacker because it's not a constant (see KASLR).
3. There is also a simple fix by simply adjusting iptables, and much/most/many network setups already drop IP options by default.
If I'm misunderstanding something let me know, but in practice this doesn't seem like it's likely to cause much damage. The people at Canonical and Redhat probably came to same conclusions and are balancing the true risk (not CVE risk level which are not very useful) with the potential for introducing a regression for their customers. This kind of stuff happens somewhat often and never catches fire like this, I think Anthropic is just fanning the flames and Ubuntu is taking the heat.
Revision: It seems like catching the race condition is not that hard, but the root exploit is very unlikely. But still, the fact we haven't seen lots of services going down indicates to me that this is overblown.
E.g. Ubuntu 22.04 Linux kernel 5.15.0-203.213 was published in Canonical's proposed kernel PPA on October 26, 2026. So just enable Canonical's proposed repository, use APT pinning to prevent automatic installation of untested packages and install the patched kernel. I agree that they need to get quicker at pushing these updates into stable, but it's not as if you don't have a choice.
That is with the implicit assumption that the mptcp exploit of this ipv4 tcp bug is the only exploit that will be found. I don't think that assumption will hold true.
A nation state actor behind a popular linux distro got discovered with keys to the kingdom and they scramble to keep their option open, while acting as if nothing has happened - that's how I see it.
NixOS also makes it much easier than ubuntu to install your own patches and version of the linux kernel.
For example, assuming NixOS had not yet released the fixed linux version, 6.18.56 (though it has), you could upgrade to it before NixOS did it upstream with this one line:
The debian and redhat based distros all make it so configuring what packages are installed ('apt install' / 'yum install') is a different operation from configuring the packages themselves.
On NixOS, the specification of how to build a package, what package is installed, patches, etc are all in the same language, and so it's a lot more natural to patch things as needed.
And also, LLMs are pretty good at generating working nix, so you can have an agent apply patches to your kernel package with NixOS quite easily. Agents can also do this for ubuntu or redhat, but in my experience they're much worse at it, and it's harder to undo mistakes if they mess up.
Substantially worse in my experience. They build the whole OS in CI which is slow and unreliable, and as a result it can take 2+ days for updates that other distros have out in under an hour. You can try mix packages from smash or unstable builds but for stuff like kernels that’s not simple.
If you pick a specific random package update, nixpkgs often has that update months to years before other distros.
If you pick a specific CVE, nixpkgs usually is better with the exception of embargoed ones, where Ubuntu, Fedora, etc get to prepare their patched packages ahead of time.
Mostly on how much rebuilding it needs (e.g. if it's a "leaf" package, or one many packages depend on).
The merging of security fixes is usually very good, also because it is so easy for anyone to just make a PR.
The security team also seems pretty competent and fast.
As a sibling commenter says, it is also extremely easy to just apply patches to your own system in general, usually with a few line of easy code max. So you can fix systems without dependence on distro maintainers.
In contrast to e.g. patching a `.deb`, you can declare the code such that the patch will still be used even if the distro releases a new package; you can carry the patch forward, and don't need to choose between {not having the patch because the distro lacks it} and {not having future security fixes because you pinned your custom .deb version}. NixOS will rebuild any future update, applying your patch to it. That's a big benefit, because it makes "out-of-tree" custom patches very maintainable.
Due to declarativeness, you can easily roll out your fix on lots of machines.
Also, the "SBOM" (software bill of materials) part is quite good in NixOS. It's very easy to determine which package uses what dependencies.
The only real drawback is CI build time when a high-dependency package needs fixing.
Due to the way Nix works with its immutable hash DAG of package dependencies, a package change will trigger a full rebuild of all packages that recursively depend on it.
For example, if you change 1 line in glibc, or libpng, or curl, or (recently) brotli, the entire distro needs to be recompiled from source ("rebuild the world"). Some of the packages, such as Chromium, can take many hours to rebuild individually. Rebuilding all-of-NixOS can take days.
In distros that can mutate packages without triggering dependency rebuilds, updating 1 line in e.g. glibc, will only rebuild that package, allowing to theoretically distribute such security updates within minutes (if done, see Ubuntu counter-example).
The mass-rebuilding is done by NixOS's binary-cache build farm. A new NixOS update is generally only released once the build farm has fully built all dependents.
(One can also opt into a "small" channel that releases as soon as only a few core packages are built, which gives you security updates faster for those. But if you do that, your computer will next start compile all huge packages such as Chromium, in parallel to the NixOS build farm already doing that. So usually people don't.)
For the recent brotli CVE-2026-111497, the timline was:
2026-10-21 node.js releases its fix for node2shell (caused by brotli)
2026-10-21 19:27 https://github.com/google/brotli/releases#release-v1.2.1
2026-10-22 brotli CVE-2026-111497 gets published
2026-10-22 06:51 PR "brotli 1.2.1" https://github.com/NixOS/nixpkgs/pull/577208
2026-10-22 08:25 PR merged to "staging" that will become rolling "nixos-unstable" in the future
2026-10-23 created https://tracker.security.nixos.org/suggestions/by-id/60353
2026-10-23 created https://github.com/nixos/nixpkgs/issues/577796
2026-10-28 CI has built a nixos-26.05 update that includes it:
https://hydra.nixos.org/build/351243680
This is the point where users can install it.
2026-11-02 CI for rolling-release nixos-unstable is still not built, 2 weeks later:
https://github.com/NixOS/nixpkgs/pull/577208#issuecomment-6573335016
So in summary:
The PR got made within 7 h
Review and merge happened within 2 h
CI took additional 6 days for stable NixOS 26.05
CI for rolling nixos-unstable is still not finished after 10 days post-merge
For our startup, I rebuilt the slice of the world we use on a 16-core CPU within a day or so, without waiting on the NixOS build farm to build all of NixOS, so we got the update significantly faster.
Also note that just patching a library in your distro is often not enough. For brotli, lots of upstream package vendor brotli's code. NixOS contributors seem to be quite good at looking at underlying issues, e.g. there's this issue "Tracking vendored Brotli decoders" (https://github.com/NixOS/nixpkgs/issues/578375) to track that. I am not aware of other distros making such efforts.
Thus:
In NixOS, security updates are great and fast for leaf packages such as the kernel, but can be slow for many-dependents packages. Much of that can be mitigated by building things yourself, which is easy.
For people who absolutely need to run 16.04, 18.04 and 20.04 without any further subscription, I recommend installing the signed kernel from 22.04 (as of right now only available in the -proposed repo). Worked fine for some 16.04 examplary machines I had around that are stuck and bumps the kernel to 5.15 (soon EOL, but maintained by ... canonical, to get security patches).
It’s not a good look that Ubuntu is taking its time with this patch even for paying customers, but I do have to question how widely exploitable this is. If your site is mission-critical, it most likely has a load balancer or reverse-proxy in front of it that’s probably already filtering it out. Companies like AWS have already confirmed that their load balancers filter it.
Remember that the AI companies benefit from creating panic every time there’s a new security exploit.
What would you recommend to use on servers? Would you host you apps off Arch? Or better to take Fedora or similar? I am genuinely interested in answers not distrowars
After painful Ubuntu upgrades in the past, I moved to Alma Linux and have been very happy. It takes a small adjustment to dnf instead of apt, but realistically I was over that hump in 30 to 60 minutes and this was before AI. With AI to translate and test install scripts and the like, it might be a 5 minute task depending on how much automation you already have in place. Though even an entirely un-automated setup that is just a README.md, claude wrote me an Alma Linux version of a very ubuntu specific project that gave instructions for Alma instead of Ubuntu, and it worked almost perfectly first time and AI was able to (with prompting) see the issue and quickly found a workaround. We're a small org, but at some point when we hit scale and have compliance requirements, a migration to RHEL is also largely trivial if/when the time comes.
Good question... I run ubuntu on servers because the LTS has clear 5 years of security fix.
I use arch linux for my NAS because it's fun and I don't care if it occasionally goes down but I wouldn't use it for production (on my NAS it's mostly stable but has gone down a few times)
So what's next? Centos is a rolling upgrade, nixos?
As always, it depends on how and what you're managing on it.
VPS/VM?
Debian is a great choice. Use it as base and run your software via systemd+podman if you want the most up to date stuff, Debian tends do lag a bit. It is very low maintenance.
Bare metal?
Fedora Atomic is awesome. It does require an update every other week since it keeps packages closer to upstreams, but this is where the immutable base shines, any issue is an easy reboot to revert. Also systemd+podman for your own software.
I wouldn't recommend Arch on servers.
Edit: clarified Fedora immutable spins are called Fedora Atomic.
Note that Fedora CoreOS is a very low maintanance atomic Fedora system designed with fully automated updates in mind, and along with the systemd podman integration you mention, can easily be set up to automatically update both OS and containers.
Which may not be ideal for serious production workloads, but is perfect for non-mission critical appliance workloads like Pihole.
I use Arch for servers too, for almost a decade, and to my memory only once I had an issue. That was booting off an encrypted RAID and some change which needed some investigation and then reconfiguring. I am planning to run them servers on Arch for as long as I can. It’s a bliss to never upgrade my system (only update it).
Similar. While theres something to be said about declarative and immutable distros, if you're not going that route a minimally opinionated distro works a treat for server workloads.
And besides, just about every workload you can containerize should be containerized. Ideally though many with more isolation than what plain old runc provides.
> ...distros run by volunteers (Debian, Arch, Alpine...) have shipped the fix. Meanwhile Ubuntu, made by a company that sells security subscriptions, hasn't.
This tells you all about the priorities of companies. It's making profit, not protecting their users. Perverse incentives and all that.
I genuinely want to understand why people use Ubuntu, and especially for servers. I’m not trolling or whatever the proper word for it. It’s not sarcasm either. I must be missing something, I guess. What is the reason? Especially if you’re not paying for it. But if you’re paying for it, I’m still curious.
It was like that when I got here. The servers at my work were all Ubuntu, so that's what I keep using. And if the servers are Ubuntu, I'll use that on my machine too.
I also ran into this problem. But it's possible to install an untested Linux kernel, and that fully solves the problem. As for Ubuntu — yes, it's terrible. Fortunately, there's a workaround.
These recent burst of major security issues really have shown that paid security updates from the likes of Ubuntu and CloudLinux really aren't worth the paper they're written on.
OpenBSD got a recent GeFS (COW FS, but far lighter than BTRFS and not to mention ZFS) update, I wish 8.1 or 8.2 had it stabilized, because the issues with FFSv2 would end in the spot and maybe even steal some server machines to GNU/Linux.
or maybe, just maybe, entertain for a second that upstream (linux kernel) shipped the original patch commit on October 1st with rollout to mainline on October 9th and disclosure on October 15th.
People with affected systems have been waiting ever since for canonical to ship ... something, anything. Or maybe communicate the blockers. Crickets, though.
It gets all the more egregious if you're a paying customer for Ubuntu Pro (which thank god, our company is not).
It is absolutely taking the proberbial piss when you put it into context of their bold shiny new ambitions posted on September 23rd on their official blog (https://canonical.com/blog/accelerating-delivery-of-cve-fixe...) ... failing every single listed requirement in that announcement, now 14+ days, after initial CVE disclosure.
No need for a tin-foil hat here at all. Ubuntu has a large installbase. Part of which hosts servers. And if I had to take a wild guess that userbase is about to shrink dramatically going forward.
People panicked about the issue can either apply a quick IPTables mitigation or install the kernel Ubuntu hasn't released to production yet. It's annoying that Canonical is late, but it's not the end of the world either.
Unlike Arch or even Debian, Canonical has dozens of kernels to test and verify. The downside of supporting your software for ten years across multiple chipsets and even offering in-between kernel updates is that you need to test and maintain a shitload of kernels. Testing all of those takes time.
I hope they do a write-up about what went wrong here but all the big companies were weeks late to the party. My guess is that some of the patches were causing issues when backported, or Red Hat would've released updates much sooner as well.
A colleague once told me not to use Ubuntu in production. I was too busy/lazy to research why. That was ten years ago. I'm glad I procrastinated in my research and just used Debian all these years.
There are a lot of Ubuntu boxen in production out there. It is basically the default for Linux VMs in Azure, the UX sort of pushes you that way unless you have a particular preference otherwise. I do have a preference, for Debian which I've used at home for many years, but in DayJob Unbuntu is close enough and seems to make others more comfortable (in part due to the impression some have that it is better supported in Azure). I'm surprised MS aren't nagging Ubuntu to pull their finger out for this reason (maybe that are, behind the scenes, but if so it isn't working).
Everything that's built by a publicly traded company is built for shareholders, not for consumer. Switch before it became unswitchable or learn the hard way.
I’ve always hated Ubuntu. I simply don’t understand the pitch as to why someone would use Ubuntu over just good ol fashion Debian. Better yet: FreeBSD.
It's the first commit listed in the 7.2.10 changelog. The CVE number isn't mentioned in the commit message, but you can verify that this is the fix by cross-referencing the CVE announcement.
In the current age of AI, open source means exploits can discovered directly through the code. The flip side is the patches can also be managed.
We are in that period between when software was good enough and when software is certified as secure by the writers.
The days of importing frameworks and libraries written by strangers is over. I would say the entire industry is not prepared at this moment for the unpatchable event where the only solution is to power off or disconnect.
Don't expect closed source to protect you. LLMs are very happy to analyse binaries and decompile functions you need. It's barely harder to deal with software you don't have the source for. I did both security and reveng work with LLMs and they don't slow down.
A hot take - agents with root access dynamically updating your system have crossed over the threshold of being more secure than not using them.
I still haven't done this for my servers with SOC2 compliance (for obvious reasons), but I've moved over my personal project servers to this pattern. They all run ubuntu and this CVE was fixed within 1hr of my agent seeing chatter on twitter about it.
Still in the testing phase of this pattern, but while I initially thought it'd be a terrible idea[1], I'm coming around to it more and more with the amount of major CVEs hitting.
beyond the nft/iptables mitigations discussed codex plopped out a kernel livepatch for my ubuntu kernels in about twenty minutes. the functions are ftrace’able so no trampoline/splice shenanigans required.
Debian is, in every way that I know, superior to Ubuntu.
- no snap nonsense where you can't turn off upgrades
- stays close to upstream LTS kernels
- does not carry around some ridiculous kernel patch set
- no irritating adware on login
I switched after the aforementioned patch set broke containers and destroyed my server instance a couple years ago. Apparently nobody bothered to check containers before releasing the kernel.
The TCP/IP stack has one of the most stable requirements bases of any component -- modern PCs can communicate with decades-old software and hardware, and the composition of layers design means the code can be easily tested, and is a great candidate for analysis via formal methods. And once you have a formally verified implementation, the stable requirements means you can make it safe and then leave it alone.
Pretty much every OS I can think of has had one of these vulnerabilities. Microsoft had a bad one not so long ago that affected IPv6 packets, not even at TCP level. Dedicated RTOS packages that run Mars rovers have had network-level code execution exploits.
Network routing is complex enough from a management point of view, doing it fast and safely is very hard. Formal verification sounds nice, but the network stack is more than a dumb pipe.
For bugs like this, I hope the addition of Rust to the kernel will lessen the UAF vectors, but I'm sure it'll be years before that happens. The binder folks did a safe rewrite and encountered downstream companies hooking kernel tracepoints for state determination, I can't even begin to guess what they'll do to the network stack and how that'll affect adoption.
Normal Ubuntu approach. Not news.
I have personally got a bunch on 10+ year old bug tickets on Launchpad and only lately got a feedback like: "is this still relevant"?
Of course, if one hides a bug long enough it will eventually disappear or become irrelevant.
We were using ZFS in prod a few years ago, and there was a one-line patch to fix data loss issues.
It took Ubuntu something like 6 months to “backport” it. I’m not at all surprised they are taking forever to patch a severity 11 wormable exploit.
Mildly disappointed, but not surprised. Anyway, the ZFS thing (and, before that, widespread systemd-related breakage of an old LTS) are why I don’t trust them in prod anymore.
To pre-empt any replies: yes, I absolutely prefer BSDs over Linux any day. But even those are flawed and I really think we missed the Symbolics golden era. THAT would be the age of "own and live in the system". OpenBSD gets closest there. At least the codebase is hackable enough.
Linux went off the fucking rails. What the fuck is that over engineered yes command?!
The OpenBSD implementation is much slower than both the GNU versions from 2015 and 2026. However, their goals are different from ours, and that statement should not be interpreted as criticism of theirs.
It makes the code way less auditable and more prone to bugs and errors. Or let the kernel change its paging mechanism and now your fucking “yes” tool needs an update to be “efficient”. The tool has one job…print yes or another word you give it. It by definition does not have to optimized to oblivion. Same goes for echo.
It’s arsinine to optimize it to that level instead of just keeping it readable and maintainable. And portable.
The gnu version is 100% not easily portable because it has assumptions about the underlying kernel.
The current implementation works on any system with read and write system calls.
The Linux optimization just uses splice and vmsplice. If those APIs are changed to avoid zero-copy, as was considered for some time after the AF_ALG security issues, it is unlikely that another API would take their place. So, no, I do not think it needs any changes if Linux changes.
> It by definition does not have to optimized to oblivion. Same goes for echo.
I don't know about oblivion, and non-portable optimizations are not good. But perhaps yes(1) and echo(1) are among the tightest inner loops of scripting. You would not want them to bottleneck the pipeline. You'd want them pumping output faster than it could be accepted or written out.
Perhaps there is an opportunity for a /dev/yes, which acts like /dev/zero, only it continually outputs whatever filename it was opened as (good luck!)
maybe once it comes out you will need to pay them to get the patch xD
I suppose this kind of stuff is why you will find some places who roll Debian in prod but almost never find Ubuntu?
on laptops etc. its less impwct because (i think) most people are sensible enough not to have all kinds of listeners open all the time?/(right guys??? ...RIGHT GUYS???)
dont forget it can also be used as LPE if its a local host listener. and LLMs can bake u a nice exploit for it too.
Go Debian or perhaps consider freeBSD or OpenBSD if your workloads permit. they are more feasible, and sensible by the day, not just trying to poop on Linux, its simply much more targeted for now, and because it moves faster, and thus is bigger, it will have more holes.
a lot of ball dropping all around lately in lots of incidents and CVE. stay safe out there!
I have the same general feelings, but then I recall my years as an OSS developer and being abused by people who contributed absolutely nothing to my projects. Not money, not code, not documentation, not even grammar corrections. I'm sure anyone who's been involved with reasonably popular OSS can relate.
I am not contributing to Ubuntu in any way, and that puts it into perspective.
(I still directly contribute to OSS and release OSS projects, but absolutely refuse to engage with the least bit of hostility. Any of that is an insta-block.)
Edit: Whoah the downvotes and comments. I'm not saying that Ubuntu is doing well here. I'm trying to point out that a a vast percentage of the complainers are not paying customers, and maybe if they did pay, Ubuntu would have more incentive and resources to work more quickly.
People are paying money for Ubuntu, though. I suppose if only the free versions were unpatched we could consider the ethics and merits of who is allowed to complain about what, but when the paying customers are also being left out in the cold I don't think your argument has much merit.
I have fond memories of burning Ubuntu to a CD being my first introduction to Linux. I chose to preserve those cherished memories rather than sully them through actually using Ubuntu.
I'll add that they were a day or two late to patch the brotli issue, other than Ubuntu Pro LTS, which was still "under consideration" or whatever they called it, for another few days to a week. https://ubuntu.com/security/CVE-2026-111497 Now it says it's fixed, but on my old server I'm still not getting the updates for whatever reason (maybe I have it set up wrong? I dunno.).
I hate to be the guy to complain about a free service (Ubuntu Pro is a source of revenue, but it's free for individuals) but if I knew this was actually was actually being offered I would (hopefully!) have switched off by now.
The fact that Ubuntu (still) hasn't patched this (despite the fact that I'm pretty sure Opus 5.5 could figure it out in a few minutes) is pathetic. And it's very annoying for me because I have two servers that I need to consider migrating off of it now because Ubuntu clearly doesn't care all that much about security vulnerabilities like this. Get your shit together, Canonical. We all know you can do way, way better than this.
Everyone is just using Ubuntu for free of charge for the most part. You get what you pay for.
On another note, you can probably easily install the Debian kernel onto your machine.
"But we need signed kernels!" Well, that's a big "I told you so" from the people that were against only a handful of distros being able to create signed kernels with MS derived keys like 15 years ago.
You get what you pay for? Honestly this is so very disrespectful of the work thousands of people have and continue to put into Free Software including all Linux distros (Ubuntu too) as well as other operating systems and software. Really really disrespectful.
Having to get the client into call just so they go and click authorisation for adding some signing keys on VMs (as it was in pre-boot stage) just to add some driver wasn't fun
I mean.. how many people are using multipath on Ubuntu? This is a big issue for datacenter systems that are using fancy networking features that Ubuntu users probably aren't.
So they do. Also they mention in the golang-announce bulletin that MPTCP might not even be required for exploitation, it's just that the PoC requires MPTCP.
The patch itself isn't related to MPTCP, but the bug is hard to exploit. AFAIK, Anthropic is the only ones who claimed exploitation using their unlimited frontier models without safety restrictions. So non-MPTCP configurations may also be vulnerable, but exploiting them could require even more resources. I've tried to trigger KASAN using Qwen 3.8 27B @ local RTX3090 - no success after 96 hours.
What difference does it make? Version N (TEH LATEST) is considered secure until it isn't and the same show repeats with version N+1 but we already know it's also compromised.
They are on my face. It's how I read a blog post and comments of people who are complaining that free software isn't being updated fast enough for them.
WTF Ubuntu! I'm not paying you for updates... so where the fuck are my updates bro?!
This doesn't work in practice. That's not really how OSS works; it's a naive interpretation. I can go into details if you'd like, but first: Have you taken this approach before? What were the results? I find it usually ends up in discussions/arguments with the owners, and it doesn't get merged. And I see the other side too; reviewing PRs is a burden, and the submitters often will fix their own problem, while introducing complexity or problems elsewhere. Also, it's generally MUCH easier for a maintainer/owner to update software than a rando who wants a bug fixed.
I fix it for myself, share it upstream, and have no fucks to give if the gatekeepers review it, reject it, merge it, or belch any purity bullshit in between.
The beauty of OSS is that you don't need permission from anyone to modify the code to your own needs.
> "The free operating system that I use is not giving me enterprise level security updates"
Canonical absolutely is marketing enterprise security updates (at least for those who pay). I don't see this in the paid ESM updates channel yet either?
> Oh and btw, distros run by volunteers (Debian, Arch, Alpine...) hve shipped the fix. Meanwhile Ubuntu, made by a company that sells security subscriptions, hasn't. This is true as of 2026-11-02 14:48 UTC.
Ubuntu is one of the larger companies in the OS space and advertises themselves as providing long term support with rapid security fixes. AFAIK they haven't released a fix for their paying customers either. If they were complaning about arch or debian then I think you would have a strong point, when those distros have fast fixes but ubuntu doesn't I'm not so sure they that criticism of ubuntu is unwarranted.
(Also, ubuntu already has the fix. What they're dragging their feet on is releasing the updated version. I don't think anyone outside ubuntu can help with that process)
Probably depends on the company. Plenty love to publish useless blog posts about how “We, a SaaS company that produces React components, fixed a vulnerability in Ubuntu Kernel” because we’re involved in all of our tech stack like that. Linux kernel, node and react is our stack and we take ownership of it seriously dawg.
The most famous not-free-as-in-beer OS that specifically marks enterprise as their target market actually only fixed this yesterday... whatever you may want to take from that.
I suspect at this point that it’s a bunch of techno-bureaucrats at Canonical who are dogmatically sticking with their release cadence because artificial justifications. I have worked in big organizations where The Process, or The $place Way of Doing Things, has become so big that the bureaucracy takes on a life of its own and you end up having a whole team of people who just manage the process so that the people actually doing the work can maybe get something done.
I haven’t used Ubuntu for a few years now but I’m glad they’re getting this trial by fire now. This new era of software vulnerabilities is going to reduce the viability of a lot of smaller distros who more or less are entirely dependent on upstream for security and reliability. I sincerely wish the Ubuntu folks well but this is a sink or swim moment, and even if they sink it will be a net positive for Linux as a whole as weaker projects get picked off like the slowest antelope in the herd.
Sorry. I just meant, Debian's free as in beer. Ubuntu can be too but I thought there was more of a visible avenue to pay for it. And I just get annoyed with the 'you are the product' as a slogan because you get used plenty, exploitatively, even if you do pay for something. And many ethical things are in fact free
The fact Debian apparently does things properly just hammers it home
Calm down, man. I think Ubuntu is doing o.k. here.
What is pretty bad that people cannot read advisories anymore and fix there machines, instead crying for their mama (in this case Ubuntu).
Use this firewall rule and you are fine - it blocks the tcp options negoation - and things remain working of course:
`
nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop
`
Worse yet, the Ubuntu security incident page[0] lists "Ubuntu Priority: High" (as opposed to Critical, which would trigger an out-of-schedule patch). There's a "Why this priority?" link that simply says:
> Why is this CVE high priority?
> See ubuntu cvss score
That's it, we don't even get a period on this TBD of a sentence. It's followed by a generic link that explains what "Ubuntu Priority" is, but that page contradicts their choice. Note that it doesn't offer any mitigations either, and even the (horrendously unclear) description is copied from the NIST page, so there's no actual message from Ubuntu.
I already had a bad feeling the first time I saw "Get more security updates through Ubuntu Pro" on `apt upgrade`, this is now the kick I needed to move to a different distro.
[0] https://ubuntu.com/security/CVE-2026-98432#priority-reason
I don't think this is fair. They don't do a good job of pointing you at their rationale which is in their security score here[0]. I ultimately had to have claude translate the kernelese in to something my small brain could understand but this is a bug that could crash your system but is unlikely to expose your confidential system data to attackers or degrade data on the system. Especially given that the exploit can only be done if packets with IP options. IP options are commonly dropped or removed from packets on the open web. You not only need a vulnerable system but a vulnerable request path through the internet which you would only know by trying this attack which is very timing dependent with the SYN,Retransmitted SYN and Reset all happening very close together. A motivated attacker could probably do this on your network but over the internet ... It sounds unlikely.
[0]https://ubuntu.com/security/CVE-2026-98432#impact-score
> this is a bug that could crash your system but is unlikely to expose your confidential system data to attackers or degrade data on the system
Red Hat disagrees[0][1]. They might be parroting Anthropic, and Anthropic might be exagerating the impact (likely!), but that's the current consensus about the vulnerability. If Ubuntu disagrees, they should have said something and not pasted "Cvss 3 Severity Score 9.8 · Critical" at the top of the page.
> A motivated attacker could probably do this on your network
I find that's still catastrophic given how centralized cloud environments are.
[0] https://access.redhat.com/security/cve/cve-2026-98432
[1] https://access.redhat.com/security/vulnerabilities/RHSB-2026...
> I find that's still catastrophic given how centralized cloud environments are.
It's not like every cloud environment is vulnerable. GCP drops these options for example.
> If Ubuntu disagrees, they should have said something and not pasted "Cvss 3 Severity Score 9.8 · Critical" at the top of the page.
Again I'm going not going to argue they did a good job at pointing at their rationale but it looks like 9.8 is from CVSS 3.0 and they did prioritization with 4.0 which is 8.3. They definitely should have put that up front.
That would still be an RCE in the default install under certain circumstances, and the security advisory has no legible description or mitigations for an issue that other vendors have patched two weeks ago.
I would be perfectly ok if they had either quietly patched it earlier (like Debian), or communicated their prioritization, or they inexplicably delayed it but provided a high quality advisory (like Red Hat).
I don't like complaining about my fellow security engineers, but this one was real bad and is still personally affecting me.
> If Ubuntu disagrees, they should have said something
Exactly. There's room for considered differences of opinion, but that consideration requires discorse and explanation! The lack of communication here is just absolutely baffling. It's like they're deliberately trying to trash their own brand.
I mean, seriously what's going on? We know they have a process for emergency kernel updates, because of course they do. If they're not going to pull the trigger on this particular one (that everyone else is pulling the trigger on) at least make the case.
Greg Kroah-Hartman the long-time Linux kernel maintainer (USB, PCI, driver core, sysfs, and -stable releases) gave a talk on LLM assisted CVE discoveries. In that talk, he downplayed those exposed CVEs from Mythos. What you described above matches his sentiment on downgrade those CVE vuln score.
See previous discussion and the actual talk on YouTube:
https://news.ycombinator.com/item?id=49929391
> but this is a bug that could crash your system but is unlikely to expose your confidential system data to attackers
Given people have demonstrated getting root with it, unlikely seems questionable
> Especially given that the exploit can only be done if packets with IP options. IP options are commonly dropped or removed from packets on the open web.
It sounds like iphones use mptcp in the wild, which use tcp options, so im not sure how true this is.
> It sounds like iphones use mptcp in the wild, which use tcp options, so im not sure how true this is.
There's so much commentary misunderstanding what ip-options are that I find it difficult to make any judgement call. I do know that I've got routers on 5 continents with hundreds of public IPs and none have triggered an IP packet with an ip-option arriving on the WAN side, or seen on the internal side other than ones I've created with scapy trying to reproduce this. I also can't get these packets to traverse any internet paths I've tried.
TCP options are quite different from IP options.
IP options are annoying in big fast routers because they have to take the slow route via CPU. As there's not a lot of use in accepting packets (externally at least) with IP options, they tend to be dropped totally (but will almost certainly be policed aggressively to the CPU as the CPU is not good for moving many packets).
Who demonstrated getting root with it? The last I've seen was "trust me bro".
Anthropic claims they have and they havn't been caught in a lie about this sort of thing yet. From a theoretical perspective, if a memory safety vulnerability in kernel network stack is exploitable, then root access would be the endgame so it fits.
So it's indeed "trust me bro!".
What exactly do you expect them to do? Publish the exploit that can root a huge proportion of all linux servers?
Presumably they will publish it with sufficient fanfare once patches are applied widely enough.
Asked claude/haiku5.5 to review that cve against my server, docker images. Claude had passwordless ssh access to that server and no root access. It did the review, confirm that server has the volubility, asked me to ran a few sudo commands, give it the output. It asked me to run a command to disable mptcp option.
I then asked it to do complete cve reviews on the host server (U 26.04 was installed a few weeks back) and docker images on that server and update the security review and added a task to do daily check on ubuntu website on kernel security update.
EDIT: Just asked claude if it can write a patch and build a image on top and fixed the issue on my server. It said it can. And point out that it can apply the 2 lines patches https://github.com/torvalds/linux/commit/e3f33b0.patch and build a kernel image on this issue for me. FYI....
A problem, at least for me at work, is this has to be communicated to the people who make the decision around whether something can continue operating or has to be taken offline until fixed. So far, said people are not particularly interested in the details of CVEs, just if it's critical and has an exploit available. Which is fair I guess, they're absorbing the risk. I would like Canonical to go a bit faster which would make my life easier.
What about an untrusted local network, like public wifi?
Yeah, their lack of a satisfactory response is the final nail in their coffin. This incident escalates my consulting advice about Ubuntu from “not recommended” to “switch immediately”.
Some of my clients may be surprised by this change, as I once advocated for Ubuntu as a good choice for a development and deployment platform. While that has not been true for quite a while, they have now jumped the shark into eel-infested waters; I cannot take them seriously any longer.
Plain Debian was always best option; even RHEL dropped the ball on this CVE and that's distro people pay for support
Not always. Notably, if you have compliance requirements like needing FIPS encryption (say because you have government customers), or that requires you to use a commercial vendor, debian won't work. And if you need more up to date system packages, or a reliable release cadence, Ubuntu might be better.
On desktop, if you need proprietary drivers, Ubuntu is easier to set up.
But yes, if debian works for you, I wouldn't use Ubuntu.
I had to deal with FIPS once because the company I worked for shipped a custom Linux distribution with the product and we had to essentially shoe-horn in some Red Hat OpenSSL packages to get it to meet FIPS requirements. What's funny is that after the customer enabled FIPS, administration became much harder, and the encryption strength was strictly worse.
Anyway, needing FIPS is something of a niche requirement. Debian or Rocky are very sane choices as a default Linux distribution for general-purpose servers until you run up against special requirements.
> Anyway, needing FIPS is something of a niche requirement.
For sure. Most of the time, Debian is just fine. But sometimes, if you have special requirements, something else might be better.
Uh, yes it will. OpenSSL in Trixie is a version supported.
https://packages.debian.org/trixie/openssl-provider-fips
It's just the library, nothing special about the OS.
https://csrc.nist.gov/projects/cryptographic-module-validati...
As far as I know, compliance comes with an external module:
https://openssl-library.org/post/2025-03-11-fips-140-3/
This module seems to be in Debian:
# apt-cache search fips | grep open openssl-provider-fips - Secure Sockets Layer toolkit - cryptographic utility
# dpkg -L openssl-provider-fips /. /usr /usr/lib /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/ossl-modules /usr/lib/x86_64-linux-gnu/ossl-modules/fips.so /usr/share /usr/share/doc /usr/share/doc/openssl-provider-fips /usr/share/doc/openssl-provider-fips/changelog.Debian.gz /usr/share/doc/openssl-provider-fips/changelog.gz /usr/share/doc/openssl-provider-fips/copyright
There seems to be the validation process, which supposedly must run on each machine it is used on.
openssl fipsinstall -out /tmp/configfile.cnf -module /usr/lib/x86_64-linux-gnu/ossl-modules/fips.so 2>&1 | tee /tmp/result.txt
--
The above are from my notes, and a test run. But I don't see how Redhat is "special" here. If the module loads and cites compliance, you comply.
> OpenSSL in Trixie is a version supported.
It isn't a validated build. It works the same, but it isn't sufficient if you actually need a validated FIPS module.
> It's just the library, nothing special about the OS.
If you need validation, then the kernel also need to be validated.
Now, it isn't impossible to get a FIPS validated system working with Debian, but you will probably need to contract with another commercial provider like WolfSSL to get validated components. Or compile things yourself. But that is more complicated and involved than just paying for an OS that is validated off the shelf from Ubuntu, Red Hat, or Suse.
I compile software every day. There's nothing difficult about it until cmake starts complaining, but I've got it back on track every time.
Companies who care about whether their FIPS implementation is validated or not would probably prefer buying from a company who sells it over relying on a guy at their company to get cmake back on track regularly. At that point, it's not just about the module, it's about custody, liability, etc.
Jeez laweez. Since when can lawyers make good technical decisions?
I saw a PIN terminal reboot a while ago and the openSSL version was ancient, pretty much historic at that point. But it has an unbroken seal on it, so it's safe, right?
The problem always boils down to money.
It isn't just compiling something that works. You need to compile it exactly as specified. And document the entire process so you can prove to an auditor that you did everything correctly. Oh, and there's a list of tested platforms, and if your platform isn't on there, which Debian probably isn't, you need to explain to the auditor why it's ok, and why it isn't reasonable for you to use one of the platforms it was tested on.
What you are paying for is not saving the time of a developer compiling something. It's reducing the friction when you go through an audit.
I wonder what the specifics of certification are. No certificate can ever prove a given binary works correctly. No one really understands how computers work, but here's a piece of paper that says Oracle Linux 11.0 is okay. It was expensive and it has a seal of approval on it, so that proves it.
What is FIPS encryption, why is FIPS unique to RHEL, and what has FIPS got to do with this CVE?
FIPS is a US government security standard: https://en.wikipedia.org/wiki/FIPS_140
It doesn't have much to do with this CVE, but if you're trying to sell to the US government, it will often be a requirement, which means that a company making money from those sales will not easily be able to move to a distro without that certification.
It's about using a certified cryptography implementation. Presumably RHEL has such a certification, while Debian has a compliant but uncertified implementation.
This isn't relevant to the CVE, but counters the claim that Debian is always a suitable choice of distribution.
>What is FIPS encryption
presumably they mean meeting fips standards https://en.wikipedia.org/wiki/FIPS_140
>why is FIPS unique to RHEL
its not
>what has FIPS got to do with this CVE?
it doesnt. it is brought up in reply to the comment.
I planned to install Debian in 2009 and in 2014 but the installer was too hard to use, the desktop in 2009 was ugly (maybe in 2014 too), I could not get a running system that I could use to work. Fast forward to Debian 10, same laptop from 2014, and I got a desktop identical to Ubuntu GNOME.
Red Hat is always slow in backporting patches to their Frankenkernel.
I don't want to run unstable, just to have recent software.
Debian for hosting anything, Fedora for development desktop.
That's been my rule for years at this point, I think I switched back to debian everywhere after the netplan changeover in ubuntu so somewhere around 17-18 (not against it in principle, just the way they did it in practice).
No real regrets either.
[flagged]
The general advice I've been seeing the past ~8 years is "There is no reason to pick Ubuntu over Debian". I don't know who the opposite advice comes from and why anyone would pick ubuntu for a server.
15-20 years ago the joke was that Ubuntu is a Zulu word that, roughly translated, means "I don't know how to configure Debian". Ubuntu was one of the first distros that allowed one to easily download proprietary WLAN drivers without dealing with the terminal, ndiswrapper, or compiling half-broken OSS implementations; for this reason it caught fire with those who wanted to try Linux but were otherwise unwilling to engage in such shenanigans. I tried it on a laptop around this time and was quite impressed. This reputation for "it just works" has carried them ever since even though other distros now do largely the same thing ( cheap, obscure, or recently-released hardware excepted).
I took the lazy Mint route with my most recent machine since I wanted to use it for light gaming with minimal fuss. I'm going to redo it with Nix sometime soon because the value prop simply isn't there and I'd like to try a declaratively-configured distro.
I recently installed NixOS on my thinkpad z16. I set up a sandboxed pi agent to help me configure it and I think it works great. (I also read enough documentation to understand the nix language).
I hade some issues with the trackpad (worse issues that it not being an apple trackpad ie). I told the agent about the problem. It inspected the config, wrote some scripts for me to run outside the sandbox that listened to the trackpad while I used in as per some instructions, and then proceeded to add a few configuration lines that solved to problem. I was pretty impressed (though I think there were maybe 3 back-and-forths with scripts to run, tbh).
They also sent out free distro CDs. That helped convince me this new fangled Linux thing might be legitimate.
Christ that was 2008.18 years ago. My Linux 'experiment' is old enough to vote
I have received cds with ubuntu 5 or 6, was surprised they actually sent those, but at one point I started using it
[edit] omg circa 2006, firefox was still new back then
I remember installing 5.10 on my family's old Dell on a day off from school in early 2006. I was probably 13.
More like 20. If I remember it right, by 2007 the Debian community was angry discussing the installation team's decision to include non-free packages in the installation media, what ended the problem of needing a wired connection during the install.
> Ubuntu was one of the first distros that allowed one to easily download proprietary WLAN drivers without dealing with the terminal, ndiswrapper, or compiling half-broken OSS implementations
None of which was a good reason to use it on servers. Even if you were familiar with Ubuntu there is very little difference between an Ubuntu server and a Debian one.
> None of which was a good reason to use it on servers. Even if you were familiar with Ubuntu there is very little difference between an Ubuntu server and a Debian one.
Something to keep in mind is that the term "server" covers a wide range from datacenter beasts pulling kilowatts per node to old desktops running headless to Pi Zeroes and repurposed cell phones, and some of those use cases do in fact benefit from access to proprietary drivers and even hacks like NDISWrapper.
Beyond that, I've seen two main reasons to use Ubuntu Server over Debian, and I say this as someone who has administered Ubuntu, Debian, and CentOS systems for years and always chooses Ubuntu or Debian when the options are open.
1. For a while there were commercial software vendors that would release Linux versions only for specific distros, and Ubuntu was on that list a lot more often than Debian, so if you liked Debian-style packaging and wanted to use commercial software there was a reason to use Ubuntu. Zimbra was one of those when I last used it in the late '00s.
2. There was a time where it seemed like every F/OSS project had a PPA which made it really convenient to install on Ubuntu with automatic updates as part of the system package manager while Debian had to manually load .debs or might not have even had a package due to older system libraries. For personal toy servers and "pet" dev servers this is wonderful, obviously far less important for well-managed "cattle" servers.
Docker, Flatpack, and to a much lesser extent Snap have pretty much eliminated these reasons though. My home server is still Ubuntu LTS because it's easier than changing it but when it next gets rebuilt things will be changing a lot. All of my work servers are migrating to Debian, we have one Ubuntu instance remaining that just had its last major service switched away and a bunch of CentOS systems on sites which are getting swapped out whenever our techs happen to visit.
> Docker, Flatpack, and to a much lesser extent Snap have pretty much eliminated these reasons though.
And also plain Debian repositories gaining popularity over PPAs. WeeChat and Synapse (Matrix) both offer one for example.
I wonder how much Raspberry Pi's choice to use Debian as the basis for their default distribution helped here, because it certainly increased the demand for plain Debian packaging of software that was previously packaged for Ubuntu.
Those are good reasons but lots of people use Ubuntu where neither apply.
I use it for Livepatch and root-on-ZFS
Same for servers. 22 years ago you could install Debian, take it offline while you follow the "Securing Debian Manual" to disable NIS and maybe disallow SSH password logins.
Or you could install Ubuntu which wanted to be secure by default. No open ports in the default install, no shared root password, etc.
Nowadays most of this is common place for distros.
[flagged]
I advocated for Ubuntu for years because it was easier to install and had excellent hardware support. For 2026 I have switched back to Debian because Ubuntu has been making my life more difficult. Ubuntu 26 basically forces you onto Wayland even though it breaks some of my use cases, particularly with screen recording. It turns everything into Snaps which is a hassle because it means I need to mirror both the regular repo and the snaps to my closed network instead of just the repo.
Ubuntu still has the superior installer by a good margin, but it does sometimes like to crash when run offline. Debian's installer at least has the option to go text only. There is also more work to do after the install is finished on Debian, but since that's a script it's not such a big deal.
The one bit of the Debian installer I dislike the most is how if you aren't online when you do the install you get a completely empty sources.list, and the Debian sources are a lot more complicated than Ubuntu's. Debian's support for third party drivers like nVidia graphics is also more complicated and confusing than Ubuntu's.
Ubuntu is a great starter linux. But you cant live on it, especially in a business.
Enterprises love paying for support contracts. If you have one, you can demonstrate something has been accounted for. A secure software without support is worse from an audit perspective than a security disaster with proper paperwork. Most of these people never actually involve support they paid for ever.
> Enterprises love paying for support contracts.
They can pay for Debian support! (I’m not 100% sure who they should go to, but e.g. Freexian are doing Extended LTS for Debian [1], so I suppose they could do a regular support contract as well?)
[1]: https://wiki.debian.org/LTS/Extended
> Most of these people never actually involve support they paid for ever.
I've only been in an involved role at one enterprise large enough to pay for support contracts like these, but that one had no trouble getting vendors onto the WebEx while troubleshooting things even if it wasn't clear yet that it was the vendor's fault.
(In fact, they were paying enough that the vendors would actually just hop in to help out with the internal configuration. The most we ever heard were grumblings that we used too high of a priority level on the tickets, but even then, the sentiment from the managers was generally "we're paying for it, and we'll handle those complaints, so do what you need to do to get them on the line.")
A quick search shows all sorts of projects choosing Ubuntu. Can you explain a project like mail-in-a-box going with it? And 5.15 kernel at that..
People make bad choices all the time for many different reasons. Usually, “it seemed like a good idea at the time” is at the top of that list.
But by definition it wasn't a bad choice (or a mistake) if it seemed like the right choice given the information available at the time. Unless you have some sort of crystal ball the rest of us don't.
A choice that turned out badly after reflection of hindsight was not in fact good. At best, it was ignorant; at worst, negligent. Regardless, unavoidable; as you surmise, no one has a crystal ball.
I deployed Ubuntu on a LOT of servers 10 years ago because at the time, they had a track record of doing good things in, with, and for, the Linux and open source community. I had already been using it on the desktop for a long time by that point and knew it well. Ubuntu was far and away the most popular; it was a very safe and sane choice.
That changed when they started heavily promoting Snaps as the next big thing and started putting features and updates behind their enterprise offerings. Basically, they stopped being "Debian, but better." And Debian also made lots of incremental improvements in user-friendliness in that time. Basically, Debian is now pretty much what Ubuntu always promised to be.
Platform support. Oracle Cloud for example only provides images[1] for Oracle Linux, RHEL, Ubuntu, and Windows Server. Anything else you have to bring your own.
[1] https://docs.oracle.com/en-us/iaas/Content/Compute/Reference...
If I try to create a new instance on Oracle Cloud, these are the options: Oracle Linux, Ubuntu, RHEL, (CentOS), Windows Server, AlmaLinux, Rocky Linux.
Anyway you are right, I would have switched already if Debian was available. I guess AlmaLinux could be an option to consider, since I've read in another comment that they've patched ahead of upstream for several vulnerabilities this year.
For x86_64, It's relatively easy-ish to upload your own Debian image, from Debian's generic cloud QCOW2 image, and it works just fine. I think ARM needs a bit more work if I remember correctly.
(But 100% agree this shouldn't be necessary).
This. For llama-cpp and stable-diffusion-cpp, you get official builds only for Ubuntu 24.04 LTS and Win and MacOS. If you want to run ROCm, support is available in the form of an irreversible install script that wrecks any amdgpu driver install and requires run level 3 ie. without GUI. Good luck with running that on anything other than the exact Ubuntu release it was created for.
Let's be honest. Pre-built binaries. Yeah. Probably shame the project into releasing the SteamOS version on Steam.
The only recent reason I’ve managed to come up with is it far and away has the best support for Nvidia’s various drivers and utilities for running GPUs and its assorted ecosystem, like Infiniband and Spectrum-X Ethernet.
If there’s another option I’m unaware of, I’d love to hear it. Also to be fair, I didn’t evaluate Sid for this, only Stable.
Certain AMD graphics drivers require specific Ubuntu releases and versions. I guess one might reasonably ask "why would you run AMD graphics drivers?" to which I don't really have a good answer. But that's why I run an Ubuntu box ;p. I'd so much rather be running Alpine.
I've set up a new server literally couple weeks ago on a droplet on Digital Ocean - Ubuntu LTS is the default choice(you can select other distros but Ubuntu is the default). So I guess I picked Ubuntu because I haven't done Linux admin in over a decade and it's presented as the default choice by a big cloud provider.
Despite the recent hate, Ubuntu is still serving me very well on all of my servers.
What's your recommendation nowadays?
Debian
The more I look at this the angrier I get. This is a CVE that Anthropic claims can get a Remote Code Execution on vulnerable systems, which includes default Ubuntu installs running any sort of Go server like Caddy. Bad enough that I shut down my personal website and self-hosted tools (sorry for any typos, my grammar checker is also down).
And this is how Ubuntu describes the vulnerability to sysadmins:
How is this in any way, shape, or form acceptable two weeks after the CVE was published?sorry for any typos, my grammar checker is also down
I assume this is unrelated to the Ubuntu situation, but how does a grammar checker go down? We've been doing offline grammar checking since computers had 64K of RAM.
Self-hosted LanguageTool server[0] with browser addon. 18 gigabytes of n-gram data plus machine learning models. You can catch tpyos on 64K of RAM, but not any deep grammar mistakes, un-idiomatic phrases, or mistakes in common proper names.
[0] https://dev.languagetool.org/http-server.html
Sounds like a lot of heavy lifting for something that is maybe slightly better than spell checking 25 years ago.
Grammatik ran in 64K of RAM on a Z80 running CP/M. (The binary included a Forth interpreter so there was a lot of straight up code compaction.) So yeah, you could catch a lot of common English-language infelicities in a startlingly resource constrained environment... in 1983. Certainly a lot more than typos.
(The reason I remember this bright and shiny data point is I spent a week or three reverse engineering it and getting access to the inner interpreter; the office staff actually used it, though.)
consider harper instead. I'm using it right now and it highlighted first two words of this comment. https://writewithharper.com/
/o\ all this just for what exactly?
To make fewer grammar mistakes.
At one point that was less than $100 of RAM which isn't a big deal for the trade.
Oh, the 18 gigabytes is not RAM, it's the storage. Language Tools indexes into the n-grams, so it doesn't have to keep everything in memory.
If you're asking a self-hoster "why" then you are asking the wrong question
well, yes. sorry.
I should have asked what is it there in replacing yourself with a mishmash of external world.
there's much more to writing voice than sticking with terrible usage.
[dead]
> running any sort of Go server like Caddy
It's so much worse than this, and there is a staggering amount of misinformation running rampant about this bug.
MPTCP is not a requirement, it can be exploited merely by sending specially crafted TCP packets with (any) IP options set. No special MPTCP support, web servers or any specific software listeners are even necessary at all to trigger it, just send the packets and boom.
I think the reason people assume MPTCP is a requirement is because that's what the PoC used... but MPTCP itself also doesn't even rely solely on IP options.
Ubuntu also does not even list a single mitigation strategy... at least RHEL did.
And like I said, any normal TCP packet that contains IP (not TCP) options can trigger the bug. I cannot emphasize enough how important and absolutely ridiculous this is.
Like the post says, this is big enough to get a massive amount of people to completely stop trusting Ubuntu entirely and jump ship.
> Ubuntu also does not even list a single mitigation strategy...
I installed newest Ubuntu mainline kernel, it did work for me:
https://kernel.ubuntu.com/mainline/v7.3.1/
I also did patch my FLOSS Go software:
https://github.com/wekan/wekan/commit/e9751b65d4
I'm maintainer of WeKan FLOSS kanban https://wekan.fi , https://github.com/wekan/wekan , and maintainer of FerretDB v1 fork https://github.com/wekan/FerretDB . There is also WeKan Snap package https://snapcraft.io/wekan/ .
But I don't work for Ubuntu, I don't have any answers why Ubuntu does not do something.
Someone from Canonical answered about kernel:
https://news.ycombinator.com/item?id=50348688
I have some publicly facing web servers running Debian and Ubuntu. Specifically, what can I do to test and see if my servers are vulnerable?
Debian (trixie kernel) 6.12.113 was allegedly patched for this bug, but there's also a .115 that's been released in the last few days, upgrade to that and reboot.
For Ubuntu (which I don't use), you'd need a 3rd party updated kernel repo, to use a patched kernel from that.
It's not an instantaneous exploit; it apparently takes a lot of iteration over the network. A lot of cloud network providers are mitigating it by dropping options at the border, but unless you test and confirm that, you should assume it's possible for a motivated-enough attacker to compromise your server.
At least for 26.04, there is a 7.0.0-43 kernel available in the -proposed repos that has the patch. Presumably planned to be made availalbe any month now.
https://wiki.ubuntu.com/Testing/EnableProposed
https://launchpad.net/ubuntu/resolute/amd64/linux-headers-ge...
> I already had a bad feeling the first time I saw "Get more security updates through Ubuntu Pro" on `apt upgrade`, this is now the kick I needed to move to a different distro.
To be clear, Ubuntu Pro doesn't have the fix yet either.
https://news.ycombinator.com/item?id=50337869
Moved to Debian few years back and never looked back. We used Ubuntu for a bunch of clients and unfortunately had to let them know they will have to migrate to Debian or similar. It's such a shame because I really used to love Ubuntu until Canonical started turning slowly into your typical everyday corporate.
As far as I know the only working exploit is working on machine with MultiTCP enabled. Redhat also downgraded the issue to "high" and also did not release a patch yet. I would have preferred a patch but I accept that they know better than me what they are doing.
Why would they take so long anyway and be behind volunteer run projects like debian? Is it something about corporate shenanigans and testing? because afaik in fedora for example firefox is always behind in security updates compared to debian.
[dead]
RHEL did release a new kernel. Presumably it has the fix (though I guess I didn't actually check)
They're totally asleep at the wheel, it's malpractice. The pitch for RHEL is highly competent maintenance you can't get elsewhere
RHEL also dropped a ball on it so yeah the alternative for paying for RHEL license is apparently "just use Debian or hire some Arch nerds"
Is RHEL really unpatched still? Looks like patches came yesterday: https://access.redhat.com/security/cve/cve-2026-98432
Thanks, I removed that part from my comment. Still, that's two weeks late.
>Still, that's two weeks late.
Agreed! I know this is a bad month, but this is poor form from several vendors that tout "we'll handle XYZ aspect of security for you".
> I already had a bad feeling the first time I saw "Get more security updates through Ubuntu Pro" on `apt upgrade`
To be clear, Ubuntu Pro doesn't have the fix yet either, in case anyone's confused.
This was an old gripe unrelated to today's issue. But your clarification is exactly why it left a bad feeling back then, the message certainly implies that my system is not getting all the security updates it could get.
I believe RHEL/Alma/Rocky has released patches today. I have a notice about they have done so.
Alma released a patch ahead of upstream again, just like they did for several other critical vulnerabilities this year.
I use NixOS btw
For the record, the kernels with the fixes are in the "proposed" repos for each LTS release:
* https://launchpad.net/ubuntu/+source/linux
You can pull them down with a "-t" added to your apt-get (but will not appear by default).
26LTS had the new kernel go to the updates/security repos on October 28.
> You can pull them down with a "-t" added to your apt-get (but will not appear by default).
How does that look like exactly?
Edit /etc/apt/sources.list.d/ubuntu.sources to include resolute-proposed:
Suites: resolute resolute-updates resolute-backports resolute-proposed
Then update:
sudo apt update -t resolute-proposed sudo apt install linux -t resolute-proposed
A friendly reminder that it's either "What does that look like, exactly?" or "How does that look, exactly?" - "how" and "like" don't go together.
As for the way to add it, the full approach should be `add-apt-repository -yp proposed`, then `apt update`, then `apt install -t resolute-proposed linux-generic`
I wouldn't be surprised to find that it is a legit grammatical construct somewhere in the English speaking world. English is... big.
A lot of ESL speakers use it this way ("how does it look like", or "how it looks like"), but it's never grammatically correct to the best of my knowledge.
Chatgpt broadly agrees with me, for what it's worth: https://chatgpt.com/share/6ae9dfa3-10b0-83ec-abff-56149ab6d4...
It has severe regressions like https://bugs.launchpad.net/ubuntu/+source/linux-oracle/+bug/...
Updated and rebooted an LTS server today. It was a disaster.
Kubernetes node went to pieces. Apparmor prevented nginx from doing anything sensible, so the ingress didn't work. Easy fix when you know what's up, not so apparent when starting troubleshooting.
One app invoked tshark in a pod, apparmor denied it.
Those two were the visible ones. Apparmor now also blocks some unix signals that e.g. postgres uses in a few circumstances - leaving latent annoying bugs.
Pod shutdown hangs. Logs indicate 7 more apps affected by the signal "armor".
We're banning any new Ubuntu installs.
Yes, my postgres pods died, so everything DB related in my cluster went useless.
Not something you expect from a kernel patch upgrade
Your comment should be higher. Most indignant comments here are variants of "Tell me you don't know about CVE triage and Linux kernel releases without telling me you don't know about them". I mean, I also don't know a lot about them, but Canonical's security record has been exemplary in my experience, and I see no solid reason to doubt their process in this instance.
First, if this CVE did truly put every Ubuntu machine on the Internet at risk, we'd know about mass compromises by now, and there haven't been any reports. It means the CVE is not trivially exploited.
Second, the gravity of the CVE dictates the security release cycle. Emergency kernel patches carry risks of their own, and it would be worse to hurry a non-critical patch and crash a part of their massive user base.
Edit: I've been enjoying this comment going up and then into the negatives, what a roller coaster.
You suggest that Canonical has concluded that this issue is not so bad and so it is Ok that they have not released a fix.
Customers and users expect alacrity for CVSS 9.8 CVEs in un-hardenable services like the TCP stack.
Whatever Canonical's security record or process has been for other CVEs does not excuse silence and delay in this case. Canonical, unfortunately, does not get to silently decide such a categorized CVE "is not trivially exploited" without criticism, and likely consequences.
Not to defend Canonical, but you can mitigate this bug by dropping any and all packets with TCP options in the headers.
Puzzling that Canonical did not list this simple mitigation in their advisory, like Red Hat did.
iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP
Redhat didn't release a patch until yesterday, so no doubt the same applies to them?
> Your comment should be higher. Most indignant comments here are variants of "Tell me you don't know about CVE triage and Linux kernel releases without telling me you don't know about them".
Ubuntu managed to release the updated 26LTS kernel on October 28, but the other LTSes have been sitting around since 26 or 28, so I'm wondering why they haven't been moved to "security" or "updates" in the several days since.
Especially since their page on it mentions October 15
* https://ubuntu.com/security/CVE-2026-98432
and Debian released a couple of weeks ago.
I'm not seeing CVE-2026-98432 included in the changelog for any of the new kernels on the 28th.
> I'm not seeing CVE-2026-98432 included in the changelog for any of the new kernels on the 28th.
The versions are mentioned in this page:
* https://ubuntu.com/security/CVE-2026-98432
I'm wondering if the CVE in question is not mentioned because it was embargoed so they did not want to accidentally leak things while the kernel went through the (public?) QA workflow. Perhaps the Changelog will be amended at some point to have the CVE?
It’s okay to have criticism, but at least be constructive about it. This “I demand to speak to the manager” energy should be kept out of open source.
The post gives no details about what this vulnerability is, how critical it is, how it is impacting them personally, how vulnerable their servers are, how they are working around it.
Just a title designed to generate the maximum outrage followed by a few meaningless lines.
> The post gives no details about what this vulnerability is, how critical it is, how it is impacting them personally, how vulnerable their servers are, how they are working around it.
Yes it does? And Ubuntu is selling security subscriptions and doing a poor job of it, These aren't open source volunteers, this is a paid product.
I read the whole post and still don’t have any idea what it is and how severe it is. Ubuntu has not marked it critical. Is there any reason to disagree with that assessment? In an entire post criticizing Ubuntu you’d think they would at least make that case.
They have also not shared why they didn’t patch their kernel directly when updated versions have been available for a couple weeks now. Why wait for Ubuntu at all?
> I read the whole post and still don’t have any idea what it is and how severe it is.
From the article the bits you need to know:
1. CVE-2026-98432 is a critical (CVSS 9.8) bug.
2. Anthropic says it built a working exploit that gets root on a server.
> 2. Anthropic says it built a working exploit that gets root on a server.
Is there any independent verification of this?
Normally what happens is that the vendors get a chance to evaluate the verification, but that in the public's interest the working exploits don't get distributed.
Lot of words to say they can just sell bullshit.
> CVE-2026-98432 is a critical (CVSS 9.8) bug
That means nothing. A CVE's score is theoretical. It's up to every individual implementation to decide how it affects them.
Can we please stop giving value on what people / companies / LLMS say?
If there's no documented research or reproducible PoC, you can just ignore it.
> Ubuntu has not marked it critical.
Yes they have, and the article links directly to where they say so: https://ubuntu.com/security/CVE-2026-98432
I think the author probably assumes that after almost 3 weeks of the entire world going ape-shit over this, most people reading their post probably know about it already, or know how to find out more, so they didn't feel the need to elaborate.
> Why wait for Ubuntu at all?
There are many reasons... businesses often cannot go this route. But I don't see why it matters unless you're just trying to attack and discredit this person because you disagree with how they write their articles.
Why are you trying to farm out so much critical thinking to other people for you? It is easy to do a quick web search and find out everything one needs to know.
Page shows
> Ubuntu priority
> High
You are talking about the company side of the issues. We are talking about the specific issue that is concerning our ubuntu servers. What is the security bug, and how can someone exploit it? Where is that written?
I'm not following, I don't believe a kernel patch like this would be limited to security subscribers. Or is your complaint that there's a security subscription program but no patch has been produced yet?
[flagged]
"Pathetic", "such a Karen" to care about a service he ostensibly paid for providing the thing he paid for. Brilliant.
He's not a paying customer, he never paid anything to use Ubuntu. You don't have to pay for security patches when you are using Ubuntu, just like any other distribution. He's a simple user, did you even read the article?
[flagged]
But Ubuntu is not some small distro maintained by unpaid volunteers; they are a corporation that offers paid support. I think it reasonable to be disconcerted when a company that you are paying for security updates is this negligent, especially when other distros have fixed this issue far more expediently.
I would expect paying customer to demand a dicount or their money back, but freeloaders get freeloader service.
They have kernels out you can install if you really need them, they're just not merged into production repos yet.
As a freeloader, I would look at how little benefit there is to paying for support and reconsider my choices. Especially when other, purely community-powered distros are running rings around them.
This is a major failure on Ubuntus part. The constructive feedback they deserve is literally the title of the article.
The post gives enough detail, there is a vulnerability that allows root access on servers on the TCP stack, so literally accessible if you are running any service. There are exploits in the wild. Debian has the patched kernel, Ubuntu does not 2 weeks after the CVE is known.
> how critical it is,
9.8 out of 10 btw.
> how it is impacting them personally,
They are clearly rather upset by the lack of an appropriate response.
> how vulnerable their servers are,
They are literally open to anyone with an AI subscription.
> how they are working around it.
They are migrating off Ubuntu.
If Ubuntu offers LTS and is catering to business it is very much open to criticism. They can take it or leave it, but anyone is entitled to an opinion about it.
The post is making 0 demands, they're made a valid statement and moving off Ubuntu.
It's a large international corporation with hundreds of millions in revenue from enterprise contracts. There is in fact a manager to speak to and I do in fact demand to speak to them.
> It’s okay to have criticism, but at least be constructive about it.
Nah, if you're dropping the ball after you said you wouldn't and I trusted that, I'm going to get angry and loud when you drop the ball. That's just reality, and Ubuntu isn't some Johnny-come-lately volunteer organization. They're one of the most well-funded Linux organizations in the world.
> The post gives no details about what this vulnerability is
It is a very famous vulnerability that has been all over tech news sites. Sometimes it is ok to assume the audience has the slightest bit of background knowledge about the topic at hand.
If it is really so famous and obvious then why has Ubuntu marked it not critical?
Congratulations. You solved it. You figured out why the article exists.
Here's 1000 picarats.
hence the headline of the post.
Neither the headline nor the writeup itself explains it. The fact that there are 500+ comments on this post and not a single one has explained why exactly this CVE needs to be fixed with urgency tells me that Ubuntu's decision is likely the correct one.
The explanation is everywhere: it can lead to RCE , researchers achieved it with mptcp but nothing prevents attackers finding another mechanism. Yes, it is hard to exploit it outside mptcp but nobody has demonstrated it is impossible, so we should be cautious and tag it as urgent
With Open Source / Free Software we're trying an alternate economic model, shooting to overtake the standard model. We rely on volunteers. It creates an awkward situation where we can't be unappreciative of effort (no matter the quality of output), but we also have to have expectations or this model is just not going to work.
So we should respectfully expect better than this. (With the caveat that Canonical is a business. I'm using Ubuntu Pro for free so I won't be berating them, but I think I paying customers perhaps should be.)
I also think that we should consider a sort of an "SLA" concept. If you say "I got you covered" and you drop the ball, I think I do have a grievance in that I could have chosen another option, and now I have to take the time to adjust. On the other hand sometimes people don't actually say "I got you covered" they say "This is a cool thing I'm working on". So something like an "SLA" could clear that up.
> at least be constructive about it
I think the proposed solution here is pretty clear. Patch the bug.
>The post gives no details about what this vulnerability is, how critical it is
what? the literal first paragraph says:
"In case you missed it: CVE-2026-98432 is a critical (CVSS 9.8) bug in the Linux kernel's TCP code. It's been there since 2016, so virtually every Linux server on the planet has it, and it can be hit remotely"
But Ubuntu is not the embodiment of "open source". It's a business. With managers...
Finally I see this mention. Thank you.
I believe you will have a ton of factual page about that. The purpose of this one is exactly what you criticise: rage. With a small error of margin a justified rage. I believe this was the reason it was chosen for submission: to show the rage.
Very helpful information, thanks!
The whole point of paying for Ubuntu enterprise services is you don't have to worry about all this nonsense. It's one thing if you're using Ubuntu for free, it's another thing when you're paying them for a specific service.
> This “I demand to speak to the manager” energy should be kept out of open source.
This. You are welcome to publish patches and demonstrate how people can fix their own machines out of band with what Ubuntu does. This costs you... 10 minutes with AI help?
While it's easier than ever to complain this year, I'm patching all the things while on a walk or not at my computer, it's great!
Welcome to the world of tomorrow
> This costs you... 10 minutes with AI help?
So it should cost an organisation that charges for enterprise-level support no time at all.
Not everyone using Ubuntu is on enterprise support, right?
The entire OS is open source. I've lost count of the number of times in my career when something like this has happened and even with the luxury of enterprise support, we couldn't wait. Just find a fast way to patch until support shows up with an official solution.
Amazing I keep getting downvoted for a comment like this on an OSS Linux distribution that you can fix yourself live in production without someone getting in your way.
Because if we were talking about a real world object, nobody in their right mind would say it is the responsibility of the customer to fix a broken object rather than the manufacturer or the vendor.
To be fair: while critical (9.8) it has an EPSS score of <1% (probability of it being actually used). According to [1], [2], and others, at worst the issue results in a kernel crash or a denial of service. I read the post by Anthropic too, but something just doesn't reconcile there between everyone saying its a DoS, and Anthropic alone claiming RCE. So far the advisories I read state "under specific conditions ... result in a kernel crash" and similar.
[1] https://app.opencve.io/cve/CVE-2026-98432 [2] https://aws.amazon.com/security/security-bulletins/2026-160-...
As the days pass the probability of it being actually used is increasing. The EPSS score is clearly just an estimate, and according to the nist cve database, attack complexity is low so I would take the EPSS score with a grain of salt.
I had the same question about the actual exploit on another thread: https://news.ycombinator.com/item?id=50319143
It’s only recently I realised that a lot of these very clever vulnerabilities are often not actually exploitable, except in quite specific conditions.
Something like this is rowhammer. Can it be exploited in a lab setting vs practically in the wild? Is fail2ban + WAF sufficient? How much network traffic is needed to remotely trigger the exploit in the field? How much inside knowledge of the system itself needs to be known?
These go from extreme edge cases to viable approaches over time, so it needs to be patched. I think the really messed up thing is the lack of communication from the Ubuntu team. If they have a rationale either way, that's fine. They may disagree on the severity, identified a problem in the fix, etc, but the lack of transparency is causing a loss of confidence in the team's abilities.
Hi all, representing Canonical's product team here. We have fixes available for Ubuntu 22.04 LTS and newer in the -proposed pocket which are being tested for stability. These can be applied by users and we published a blog with the details. We sincerely appreciate the feedback and will follow up as soon as we can with more information https://ubuntu.com/blog/fixes-available-in-proposed-pocket-f....
This really needs to be hot fixed and just fast tracked to release. It’s for sure costing Canonical’s image and makes it difficult to continue to consider Ubuntu for serious server deployments going forward.
The fix is available in the -proposed pocket for users who perform their own kernel acceptance tests. Under our unified two-week kernel SRU cycle, in the first week we build and smoke-test kernels and publish them to -proposed. In the second week we run certification and regression tests on Ubuntu Certified hardware. Once that testing completes, the kernels are released to the -updates and -security pockets. We keep this step to avoid regressions, and we think it’s the right balance between speed and reliability.
IMO Three weeks is not a right balance of anything. I don't blame you personally, but taking this long is completely unacceptable. These issues are going to keep happening even more frequently as time goes on, so something needs to change. Your customers are going to start blaming you (even legally) for their systems getting hacked due to your company's negligence.
I will not be using Ubuntu for any future desktops, laptops, servers, containers or anything else.
Why are the relevant packages not available in the main or even security repos?
Three weeks is plenty of time.
I knew what this is about before clicking the link. While trying to find remediations for vulnerable systems I was also looking for any kind of "official" statement on literally WTF is going on here from the Ubuntu side, but I haven't been able to find one yet. I guess it has to go through the "hacker news puts enough attention on it for someone to care" phase which we all know so well...
If you had to manage what has become critical infrastructure around the globe using something like Launchpad, you'd understand.
It's not optional.
Have companies been compromised because of this vulnerability? Ubuntu has an absolutely massive install base. The lack of notable incidents suggests that 9.8 might not reflect real-world well.
Maybe it's time for StealMyBitcoinV2…
I think the official CTF is up here:
https://ubuntu.com/security
server: nginx/1.14.0 (Ubuntu)
^this sure made my day, lol
thanks for that :)
Lool.
List of vulns in nginx/1.14.0: https://www.cybersecurity-help.cz/vdb/soft/f5_networks/nginx...
Also https://nginx.org/en/CHANGES-1.14
Backported security patches don't bump the version string.
If someone does a v2 let's hope they make sure it's actually exploitable when they set it up so they don't leave hundreds of people with the assumption that the cve is not a big deal when the CTF was just misconfigured and the system got pwned in less than 2 hrs after they fixed it
CVSS in general is not the best proxy for "real world impact". You could have a 10 on a software thats only deployed once and the impact would be tiny. In this case, multipath is not used that much (except by go).
Go is everywhere in server environment. It's absurd to claim that multipath is not used that much. Maybe it's me, but go literally everywhere around me.
Also this vulnerability is not strictly about mptcp, although the exploitability is not clear.
But they have very valid point: a CVE 10.0 with root RCE on twenty internal servers is lower risk than one vulnerable internet-facing server. All need to be patched, but the one on the Internet is your critical risk, the others are medium at worse.
No this vulnerability is about IP Options, not MPTCP.
Any go service exposed over the internet for me is through an apache reverse proxy. Does that preserve MCTCP? Probably not, especially on an EL system...
It's trivially easy to disable multipath in Go.
Contrast this with: "The Gift of It's Your Problem Now"
We keep doing this to ourselves. Heads should roll at Ubuntu. Start that process right now? You can't. You see, nobody is directly available to sue. It does seem that nobody ever truly cared about that. The insecure codebase and tech debt shall continue to grow because that is the gift.
https://apenwarr.ca/log/20211229-the-gift-of-its-your-proble...
I think it's less of a concern over the internet because the kind of packet necessary for the exploit tends to be filtered out, but it's pretty scary as an escalation mechanism from e.g. an end-user device to a core server.
Much like with PHP2Shell, it doesn't need to be utterly trivially exploitable to be a big concern.
Here is Ubuntu’s webpage on this vulnerability:
https://ubuntu.com/security/CVE-2026-98432
It’s still, over a week after disclosure and patches, unpatched in Ubuntu.
As for me, a part of me wants to move over to Rocky Linux 10.
Yeah that literally is in "does not compute" territory for me. That page literally opens with "Ubuntu priority High [..] 9.8 · Critical [..] Publication date 15 October 2026 [..] Last updated 30 October 2026" which is exactly why "WTF Ubuntu" is the right response here.
I don't quite understand this page. I thought the kernel binary was in the `linux-image-` packages in Ubuntu.
For example, I have linux-image-generic installed, description "Generic Linux kernel image This package will always depend on the latest generic kernel image available." and then "Depends: linux-image-6.8.0-147-generic, linux-modules-extra-6.8.0-147-generic, linux-firmware, intel-microcode, amd64-microcode"
Why isn't there linux-image or linux-modules-* listed as an affected package?
First I thought it was the source package / binary package distinction, but e.g. linux-image-7.0.0-38-generic says "Source: linux-signed-hwe-7.0", and linux-signed-hwe-7.0 isn't listed as an affected package either.
So what's going on here?
Yeah.
The page lists affected package `linux`.
https://packages.ubuntu.com/noble/linux (404)
The page does not list any linux-image-* packages but as you say: https://packages.ubuntu.com/noble/linux-image-generic
It sure feels like this advisory wasn't written or even reviewed by a human... Not a great look.
Have a look at the bug page for jammy
https://bugs.launchpad.net/kernel-sru-workflow/+bug/2171802
It seems to have passed everything but testing?
They could use better communication, but if they arent happy with testing a kernel update for something that hasnt been exploited in the wild a few more days making sure its not going to brick a bunch of servers is probably a good thing.
> Rocky Linux 10
Does Rocky use their own community-built packages, or does it use RHEL's?
Because I don't think Red Hat have released patches yet either?
It’s fixed in RedHat:
https://access.redhat.com/security/cve/cve-2026-98432
For RedHat/Rocky 10:
https://access.redhat.com/errata/RHSA-2026:93413
Also, a mitigation:
https://access.redhat.com/security/vulnerabilities/RHSB-2026...
It isn’t quite in RockyLinux yet, but Rocky has a special security repo for getting updates quicker than the RHEL → Rocky security update path:
(This command is run every time one needs an urgent security fix right now when using Rocky Linux)Reboot to have the new kernel
This is how to get the patched kernel right now if running Rocky Linux.
Here is the patched kernel (`rpm -qa | grep kernel-6`)
More information:https://rockylinux.org/news/2026-05-14-introducing-security-...
https://forums.rockylinux.org/t/cve-2026-98432-any-roadmap/2...
[dead]
14.04 LTS trusty is not vulnerable fyi.
And only a measly 12 years behind! People that didn't migrate their systems to python 3 are in for a treat.
Canonical still maintains it. If you're just hosting some HTML or even PHP, you have a comfortable amount of time before you need to upgrade, assuming you're a paying customer.
I jest, but we had (HAD) an Ubuntu 18.04 LTS that received the backported patch for PHP2Shell, even if the version wasn't supported officially by PHP.
This is why I insist our developers use the Ubuntu repositories instead the official PHP ones: besides possible instability, PHP doesn't do ancient backports.
Why Rocky and not Alma?
Rocky was created by one of CentOS’s founders, so is closer to CentOS’s original vision. It’s also closer to upstream RHEL. Alma is more a minor fork from RHEL than a RHEL clone.
When AWS is shipping patches for Amazon Linux 2 and Ubuntu is still waiting.. yeah.
I get the frustration, but isn't there an iptables rule that is a viable mitigation? Why not deploy that first?
Because you shouldn't have to do mitigations for this level of severity while waiting weeks for OS patch. I did that, but now I'm waiting for patch to unwind my mitigations.
Because that doesn't allow for sensationalizing the frustration.
Agreed, it also wouldn't give free advertising to the OP author or to Anthropic who he gives a generous nod to.
Why do you ask such simple and obvious questions!? :-P
nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop
lol thank you friend :D
Talking of which, is there a link to the temporary fix?
`iptables -I INPUT 1 -m u32 --u32 '0>>24&0x0f=6:15' -j DROP`
(Taken from https://aws.amazon.com/security/security-bulletins/2026-160-...)
You can also use the following Suricata rule if your network firewall supports it:
`drop ip any any -> any any (msg:"CVE-2026-98432: drop IPv4 packets carrying IP options (IHL > 5)"; ipv4.hdr; bsize:>20; classtype:bad-unknown; sid:1000001; rev:2;)`
[dead]
" Anthropic says it built a working exploit that gets root on a server. A total takeover."
From the linked Ubuntu CVE page
" Vulnerable system - Confidentiality impact Low
Vulnerable system - Integrity impact Low
Vulnerable system - Availability impact High
" suggesting it's more of a denial of service. So which is it, there are dozens of kernel CVEs fixed in the linked debian email.
This is what I want more information on, especially before we start pitchforking ubuntu or whoever
It's not *just* Ubuntu is it? I think Redhat still hasn't released any patches? (their status still says 'ongoing')
I think they shipped patches yesterday. Which is still a long wait.
https://access.redhat.com/security/cve/cve-2026-98432
They included the simple mitigation of dropping packets with IP options set.
All the people working at Canonical have gone through the Canonical hiring process, which is quite possibly the worst in the global industry and I can't imagine anyone competent getting through it.
maybe they also use 8 stages and several months for their security fix process. Just to be sure... ;)
I wish I could work at Canonical. Unfortunately my high school math scores were too low.
Which makes it more people actually working on Ubuntu than most other distros.
It was bad in 2015. I have watched people leave and come back though, which says something.
maybe this was the plan all along.
What is keeping people on Ubuntu instead of just using Debian? I'm genuinely curious. What is Ubuntu offering that Debian doesn't provide?
I think it's just brand, ubuntu was what I knew from using it as a personal desktop and then it's the default/most obvious option for a lot of providers, I think even 10+ years ago AWS EC2 defaulted to it above Debian, digital ocean too I think?
I don't remember why exactly but it was definitely just 'linux VPS = Ubuntu' for a long time. I think they got reputation as being the 'just works' option because they were happier to include some non-free graphics drivers etc where Debian was the more pure option but most end users didn't care
But since they added snap and I started running into issues with trying to install Docker etc a few years ago I default to Debian now and most of the time I don't even know which it is.
Stable Debian is using Linux 6.12, if your laptop has modern hardware what do you do? Can't use wifi?
And don't get me started with Debian testing. I want a LTS distro not a testing one.
> Stable Debian is using Linux 6.12, if your laptop has modern hardware what do you do? Can't use wifi?
And Ubuntu 24.04 LTS is using 6.8.
Ubuntu releases a new version every six months, but an LTS — which is probably what most people run in production — only every two years. Debian releases come out every two years.
So if you only run Ubuntu LTS, the release cadence is the same as Debian.
I think you're forgetting about Ubuntu 26.04 (LTS) that is using kernel 7.0.
> I think you're forgetting about Ubuntu 26.04 (LTS) that is using kernel 7.0.
Which only came out a few months ago, and which only recently released its .1, so the do-release-upgrade message only recently appeared for most people.
I'd be interested to know how many folks have changed their current production over to 26TLS in the last six months. I'm guessing not a lot.
So yes, there is a newer LTS, but what is its current market share as compared to 24 TLS (or even 22LTS)?
Ubuntu releases its LTSes in even years, and Debian does its releases in odd years:
* https://en.wikipedia.org/wiki/Debian_release_version_history...
This is why Ubuntu also has Hardware Enablement (HWE) kernels[1], which are fully supported on LTS releases. The current Ubuntu 24.04 HWE kernel is 7.0.
[1] https://ubuntu.com/kernel/docs/reference/hwe-kernels/
Debian does have the concept of Backports, which includes kernel(s):
* https://wiki.debian.org/Backports
You can use backports if you want a newer kernel, e.g. trixie-backports has 7.2.11.
That, or just pick the kernel package from unstable or testing. Apt is smart enough that mixing packages from different versions of Debian works just fine.
(I mean nothing is 100% but I've been mixing packages for like 2 decades now and literally can't remember any specific trouble resulting from it.)
> That, or just pick the kernel package from unstable or testing. Apt is smart enough that mixing packages from different versions of Debian works just fine.
While I won't deny that this may often work, I disagree that it's a good idea, and that `apt` being smart is sufficient to guarantee that this works (or keeps working in the future).
Pinning specific packages from `testing` or `unstable` is explicitly discouraged, for very good reasons covered by this classic link: https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_Frank... .
Arguably, the backports kernel is the right choice to get a newer kernel on Debian Stable. Indeed, in the past, the backports kernel could take awhile to update, but no more - case in point, `trixie-backports` currently contains `7.2`, same as `unstable`.
I'd be wary of mixing software packages from different releases because their libraries might interact weirdly. But the kernel should be more isolated. Not isolated enough?
Either way backports does sound like the best option, sure.
It's not apt not being smart that can cause troubles when mixing packages from various suites. There's no reason to mix in cases where you can just use backports instead.
> I want a LTS distro not a testing one.
You either want to have the new stuff or LTS. You can't have both.
Debian testing is way more stable than Ubuntu stable. In Debian's parlance, Testing means "release candidate", actually.
If you want real testing, you should run "unstable". If you're in for fun, try experimental.
Running Testing on my desktops and stable on my servers since forever. None of them broke, none of them created problems.
I don't care Stable running 6.x.x. It gets security updates in less than 24h, and is applied automatically before I wake up, and doesn't ship coreutils with 104CVEs, just because it's Rust.
Testing doesn't get timely security updates. It's not for serious people with production systems. It shouldn't even be a debate.
I believe I need to reiterate: Stable is for servers, testing is for desktops if you're not directly exposed to internet.
Again. Stable is for servers, testing is for personal use.
I never argued otherwise, ever.
Google disagrees - https://itsfoss.com/goobuntu-glinux-google/
Debian security team used to offer support for testing, but as the distro grew and attack surface increased, that was dropped. However, security incidents are patched in unstable as well and they float up to testing relatively quickly (for a desktop system, anyway). When things freeze, security updates directly land on testing as a fixup polish.
However, while Testing is "relatively secure", it's never "Server secure". I'd never use testing or testing packages in stable or any server for that matter.
[dead]
The comment you're replying to makes clear that they're not using it on servers. I do the same thing (testing on my laptop(s), stable on my servers); you just have to commit to keeping track of what's going on and manually patch if you think that it's necessary.
I have to add that for me, testing definitely breaks stuff sometimes. Nothing beyond my ability to fix, though. Nothing beyond anyone's ability now that AI is around.
> I have to add that for me, testing definitely breaks stuff sometimes.
That's interesting, can you give an example? Asking as a curious Debian user.
Testing is the staging area for the new Stable release.
However, one thing that many people don't know is that Testing enters a package freeze every time a new Stable release is to come out. And this freeze can last anywhere between 4 to 7 months. So for that time period, it stops having frequent updates and becomes essentially a stable distro.
This and other issues in parent comments is exactly the reason why I switched to Fedora.
You opt into backports and run the shipping 7.2 kernel: https://packages.debian.org/search?keywords=linux&searchon=n...
It's not 'as supported', sure, but I'll also note that wifi, at least, has worked on pretty much every modern laptop which I have installed Debian upon.
> Stable Debian is using Linux 6.12, if your laptop has modern hardware what do you do? Can't use wifi?
Why not just install a newer Linux version from the official backports repository if you need it?
https://backports.debian.org/
Well you may want to know that Ubuntu LTS releases are based on Debian unstable, not even testing...
I hope you realize the irony in your comment. Guess where Ubuntu packages come from?
> Stable Debian is using Linux 6.12
But nobody runs Debian stable on their laptop.
They run Debian unstable or testing, with firmware.
And everything just works
> what do you do?
You get 7.12 from backports?
Building your own kernel is always an option, just like it was 30+ years ago.
[dead]
Back in 2005-2008 or so, I think Ubuntu was a genuine breakthrough as a polished desktop version of Linux that set a standard that various other distros, eventually, caught up to. I think Cinnamon and other distros eventually caught up on polish.
They also had credible commitments to long term support that brought people on board. I think that was enough to get them on the map, but personally as a desktop user, I haven't used it in a while, mostly sticking to Debian and Arch.
I think you are right about the branding / reputation. Personally I heard negative things about Canonical and I heard that they just basically follow Debian, so why not use the original? It's been a great experience so far. Perhaps because Debian moved to include proprietary drivers out of the box now it is extremely easy to set up.
Yeah this was the same for me. When I first made the switch to Linux for my dev machine Ubuntu was the distro I was by far the most familiar with so that was just the default choice. Later on after learning more and seeing how Ubuntu progressed I regretted not going straight to Debian.
The brand I associate with Ubuntu over Debian is increased RAM usage and extremely low performance of the UI.
Using linux for over 25 years now. Tried ubuntu once. Immediately dropped it when I saw an ad in the motd. Not a serious distro in my eyes
For us slow kids in the back, can you link to a .ISO-file of your favorite Debian?
Ubuntu found me (finally, with the tutorialhelp of a localLLM) in 2026, and I don't trust most of the opt-outs.
You are kidding, are you not? https://www.debian.org/download
Guy who can set up a local LLM but not navigate to debian.org
Times are changing! Remember when it was easy to set up WiFi, but difficult to call your doctor and get an appointment?
Now my friends don't have trouble calling doctors, but can't set up port forwarding (not like any games require it anymore).
In the US, my experience is that it's more difficult than ever to get an appointment with a doctor.
Here in NL as well. I attribute it to population ageing (babyboom generation), but AFAIK that issue is much less severe in USA than other countries which suffered in WWII. China is going to have the issue severe due to the one child policy. That population is going to get reduced a lot (not taking into account migration).
In my EU country, making an appointment got extra steps asking about one's mental state, namely depression or loneliness. One wonders if this age of social atomization, people (probably mostly those elderly) are making unnecessary appointments just to have someone to talk to.
That may be part of it but my guess is that since patients tend not to proactively mention depression and loneliness to their doctor, the doctor's office wants to know in advance whether they should be referring you to a mental health specialist.
>can't set up port forwarding
After October 2026, nobody should be port-forwarding IMHO.
I am next to learn about the "tailscale options" of this new world.
Wish us all luck.
Why not?
Local minecraft server definitely requires port forwarding at the router... as I've learned to my chagrin that Starlink doesn't support port forwarding... Goodbye self hosted minecraft. Did it for nearly a decade and cannot anymore.
If you're gaming friends can use it, IPv6 should work.
The other day, I sent a friend a link to my project. He asked, “When can I use it?”
I was confused because the project was already available, with detailed setup instructions, an `llms.txt`, and everything else needed to get started.
Then he showed me a screenshot of him asking ChatGPT about it. Apparently, ChatGPT was using some outdated cached information or something, because it gave him a wall of text explaining that the project was still “coming soon” and wasn't ready to use.
If he'd just opened the landing page, he would've seen that the project was already available.
I just wanted a human recommendation; don't trust the LLMs at all.
Thanks for the link (above).
There literally is a huge "Download" button on the debian.org homepage linking directly to the ISO. Is it even possible to make it easier?
Honestly didn't even know if it was something [genericized, or specific?] like "fedora" or "ZFS" (where there are multiple wrappers of it) so thanks for all the help from everyone.
Now I have learnt something.
Try here...
https://distrowatch.org/index.php?distribution=debian&releas...
Thank you for this human recommendation.
I am definitely still learning.
seriously? how'd you set a local LLM up if you don't know how to figure that out?
seriously: I am a bluecollar electrician that has absolutely no clue what I am doing. I have several machines because I constantly >BRICK< OSes...
As I only really learn visually (i.e. I love GUI environments), LLMs have enabled me to (quite dangerously, I might re-enforce) finally explore Linux (from MacOS for ~40 years).
I have tried for a long time (to adopt any Linux) – the fact that an LLM also won't be a sassyb when asking simple questions... is one reason I am so comfortable with my/our future(s).
you aren't exploring anything if you have no idea what you're doing! you're playing pretend while not actually doing or learning anything. what's the point?
Isn’t that exactly what exploring is?
By using a LLM, maybe ?
While I have your attention, can you constrast this human comment with your [presumably] human-derived username?
–ProbablyNotMachines
> What is Ubuntu offering that Debian doesn't provide?
Surprised how many answers here are on "social" reasons, and ignoring that Ubuntu does provide genuine additions to Debian.
Ubuntu includes additional proprietary drivers to Debian. So there are legitimate hardware cases were Ubuntu will work out the box and Debian won't. I can't speak for how many people need those drivers, and how much of choice is down to defaults/inertia etc.
From hearing interviews with PopOS folk, I think this is also a big reason people choose Ubuntu as a base for a lot of Distros instead of Debian.
Using Ubuntu as a base became popular partly for the hardware support, codecs, ease of installation. Typing this from Linux Mint, which offers both the default Ubuntu based edition, and LMDE (the Debian Edition).
Debian has caught up, but it's been a minute since I've installed it.
How many of these additional proprietary drivers are needed on cloud servers, which are based on popular hardware configurations?
What are the numbers of people still installing servers on the real hardware and needing these proprietary drivers?
to capture the cloud market, you also have to capture the mindshare at the desktop market. Do you think a new Linux distro comes out and people just install it on their servers? They try it out on the desktop first to see if they like it. It's why Fedora exists to get people into RHEL.
Evaluating server distro on a desktop with a potential need for proprietary drivers (that was the point) doesn't seem like a sensible way to test how it behaves on a cloud.
Yes I think people try the new distro for cloud by using it on a cheap cloud. Much cheaper and less time consuming than actually reinstalling a desktop. Unless one wants to build emotional attachment to one or another distro instead of testing & measuring things.
Precisely, I really don't follow this discussion. Cutting edge drivers is what I want on my gaming PC.
Is AI changing the game where more people want bare metal and GPUs with proprietor drivers?
A fair few years ago I did run Ubuntu on my desktop and laptop when I wanted some more similarity with my servers which ran Debian.
And similar breakdowns with Fedora/RHEL.
But Ubuntu or Fedora on a server? No thanks.
> Precisely, I really don't follow this discussion. Cutting edge drivers is what I want on my gaming PC.
I get the sense that the OP of this particular thread was asking about Ubuntu in general, not just the server. If it was the server, I'd understand it, but Ubuntu on the desktop still makes sense. And yes, Ubuntu is in my gaming laptop.
> Is AI changing the game where more people want bare metal and GPUs with proprietor drivers?
Yes, for GPU workloads or just raw container orchestration platforms. Or gaming!
> Fedora on a server? No thanks.
Fedora's pokemon evolution turns it into RHEL, with not much change.
> How many of these additional proprietary drivers are needed on cloud servers, which are based on popular hardware configurations?
A lot of those are running on bespoke hardware specific to the hyperscaler.
The traditional answer is that Debian is a bit slower-moving in both the Linux kernel and userland, so people who want current versions of popular software often find that they have to do some extra work in Debian.
A gradually increasing number of popular userland applications have been publishing their own apt repositories however so this is less of a problem now than it used to be.
Over the years though I've found that I much prefer Debian's relative stability and more thoughtful, if slightly plodding, release cadence.
Ubuntu just copies Debian's packages. The release cadence is the same: 2 years. It really is just intertia at this point.
Ubuntu issues a version release every 6 months, and there are updated packages in the interim.
I'm on Kubuntu (home installs) but have been looking to move since Ubuntu went over to Snaps and started breaking everything (MX looks most likely for me). The task of moving the family over is stopping me; I've been using Kubuntu for a very long time now.
And most don't use interim releases. Alan Pope of formerly canonical said multiple times that by their educated estimates LTS releases have something like two orders of magnitude more users, and interim is really testing ground for LTS.
Just use debian testing.
You can just use Debian Testing/Unstable. It's good enough that's where Ubuntu sources their packages anyway.
No they don't?
Debian is still on Python 3.13 while u until is on 3.14
That's just ONE example out of many.
Debian is currently on 3.14.8.
Prove it
Debian repositories are public. You can just look in there.
Back in the day in 2008, Linux was niché.
It had issues all the time, and finding solutions required searching online, manually. Time consuming, difficult process. Very un-beginner-friendly.
From the throve of all possible distros, one stood out. Ubuntu. Very popular. Askubuntu Forums (with coffee beans denoting ranks) was the place when, 9/10 times, the answer to your problem could be found.
So when your fedora friend cried trying to get his camera and sound working, you either found the solutions already, or asked for them and got them. Usually the former.
That was the biggest advantage of Ubuntu. Big community and wealth of troubleshooting knowledge already available. And it had the opinion of a beginner friendly system. Which made the community grow and created a large market/userbase for help threads/tutorials.
Add to that, that people are creatures of habit and 'voila - you have a lot of people sticking to Ubuntu just because they never got so pissed at them that they would change their distro.
Is Debian still considered beginner un-friendly or had it improved in that respect?
I think it's improved, but I installed Debian on a laptop recently and the fresh system came up without wifi, which was bewildering because it connected to wifi during the install process. Took me a bunch of troubleshooting to find a rfkill setting buried in the system.
AI: you probably turned on airplane mode
me: I definitely didn't
So I love debian but it's still rough around the edges and I'm not sure I'd recommend non-technical people dive in.
This has been my exact Debian experience since I tried it on Debian 3.1. On every system at least one of network, sound, display, or power management just wouldn't work out of the box even if they did in the installer.
I ended up on Mint because I consistently found that Debian was willing to compromise their philosophy for the live distro installer, but they would never warn you that you were about to reboot into an air gapped system.
yeah, I have found Linux Mint Debian Edition to be much more user-friendly than Debian
It's much better these days.
The old installer (boot-floppies) was legendarily prickly at the time Ubuntu was introduced, but it's long since been replaced by the much friendlier debian-installer. And the default install images now include non-free firmware by default, so modern wifi, bluetooth, and graphics hardware are fully supported.
To be honest, Debian now tends to be fairly vanilla and boring and it's actually Ubuntu that often ends up being a bit weirder. For example, consider how they treat the Snap packaging system for consumer software, or the rust rewrite of coreutils. Debian provides both as supported options (of course it does, Debian supports pretty much everything!), but Ubuntu pushes them to all users by default.
Ubuntu is a Debian distribution that releases more often. A faster update cycle for their packages is basically their entire reason for existing.
I may be biased as a Debian user, but if Ubuntu now reacts slower than Debian this may push some people to reconsider their choice.
If we compare Debian Stable to Ubuntu LTS, it's the same update cycle.
So Ubuntu LTS is pretty much Debian Stable with some different defaults (more opinionated, for better or worse).
For me it's just because I've been using Ubuntu full time since 2008 and has served me well my entire career, I think it's fair to say it's the flagship desktop OS that introduced many to Linux.
I feel like we're close to a post-distro era of operating systems though. My ansible playbook customizes so much already it wouldn't take too much more to just start from debian tbh.
Me same. I'm on ubuntu since 16.04 and it's annoying switching, because I'm used to it so much. Definitely switching on Debian, because they're not shipping software through apt anymore (eg. browsers). I'm running that through nix right now, and I don't want to deal with this nonsense.
I was thinking of just going entirely to Nix. The last time I tried it was 2021 (on a dual boot where I also tried Arch cause my colleague was bemoaning my Ubuntu usage). Yeah, it is annoying having to look up how to configure things the Nix way, but it all makes sense and it stems from the fact every application does it 'their way'.
Either way, I just wanted to note you can use APT to include Mozilla's Firefox and Thunderbird repo. That way, you get a .deb from them.
One specific thing I like about Ubuntu: I know a new version gets released every six months (I believe OpenBSD innovated this?) and the version is recognized by date. The LTS is released every two years around april in the even years. Otherwise it is april/october.
> it's annoying switching, because I'm used to it so much
Since you're switching to Debian, could you tell me what you don't understand in Debian that was working fine on Ubuntu for you?
I am not an Ubuntu user, so it's hard for me to know. But I find it very surprising that after 10 years on Ubuntu, it would be "annoying" to switch to Debian.
For me, it's not so much "what does Ubuntu have that Debian doesn't" and more that "just use Ubuntu" has only bitten me twice.
It's 2009 or so and I want to try Linux. "Just try Ubuntu" they say, and I have a good time. I see that many "How to use X on Linux" guides, or FOSS software, often build for only Debian, and sometimes only Ubuntu. This is fine until snaps give me huge problems in 2018, and so I completely stop using Ubuntu desktop.
Now in 2026, I manage three servers (two on Ubuntu), one Raspberry Pi (on Ubuntu), and two Linux desktop installations. I stopped using Ubuntu desktop in 2018 but snaps are less problematic for my server workflows, so now I have three Ubuntu server installs. On my desktops and my one non-Ubuntu server, I find myself sometimes missing Ubuntuland. (These aren't Debian though, so I might just be missing Debianland.)
"Just use Ubuntu" is now something that has bitten me in using servers. Two bites in 17 years is a fantastic track record. But this slow response to a CVE fix has me looking at Debian, and this has shaken my faith in canonical. "Do they pull in upstream security fixes quickly" is one of my first questions for any FOSS I use.
But my servers aren't Nix or IaC or whatever, and so... Taking them down and putting them up would take a lot of time and risk, which are two things I'm not so willing to spend. Maybe it's 10 minutes, or maybe there's a bandaid fix I have from 2023 that I forgot about and would need an hour to re-derive. So, I find myself taking the security gamble instead.
Ubuntu offers a path from free use to paid first party support. For me, that makes it very attractive for a startup or small business that may want to add a support contract later. Ubuntu makes it a lot easier than Red Hat. Paid support for Debian is via third parties. Ubuntu is a solid distro, although I think Debian is a better one if paid support isn't an important feature to have.
Ubuntu has a timeline for how long they will provide updates for a given long term distribution release. I moved over to Ubuntu back when CentOS was converted in to a Fedora type release without a long term commitment to providing security fixes.
I might be moving over to Rocky Linux 10.
This is the big reason that I see a lot of companies using it over Debian.
Five years of guaranteed updates, with an option to pay for another five years ticks the box for accreditors and the like.
The much vaguer Debian policy that a release will be supported for some undetermined period based on how frequently they release, and then get some kind of volunteer-based LTS support for a couple of years after that, and then maybe further through some third-party ELTS program is a much harder sell.
This. I can't believe not a single comments above this one addressed the previsibility Ubuntu offers over Debian. It was even one of its founding reason[0]:
> Predictable and frequent release cycles
[0]: https://web.archive.org/web/20250504071247/https://www.infor...
We migrated to Ubuntu from CentOS as well. It was simply because Rocky wasn’t established enough at the time and we haven’t had a reason yet to again look elsewhere. Tho we haven’t also phased out most VMs for containers of some sort.
Install Ubuntu and you get 10-15 years of support of your current software stack.
Install Debian and you get 3-5 years of support.
Ubuntu also invests a lot into their desktop experience while Debian is closer to stock Gnome. That's more of a preference thing, though.
Debian has also traditionally been a pain to use with proprietary software. Nvidia drivers, WiFi firmware, you name it. It got better in the past years but it's hard to shake the bad name.
> Ubuntu also invests a lot into their desktop experience
Unfortunately that's been dwindling. Canonical seems to be focused on servers and virtualised instances. The desktop experience is stagnant.
I disagree, 26.10 has me actually using Gnome and not pulling my hair out for the first time in my life. The Ubuntu extensions to Gnome make it way more usable for me, the theming is attractive and consistent, the installer is better than ever.
It's not perfect but it's a big step up from a Debian ootb desktop (unless you really like vanilla Gnome which, more power to you, but i don't)
> The desktop experience is stagnant.
When did you last use Ubuntu desktop?
The new release has a lot of cutting-edge stuff:
https://documentation.ubuntu.com/release-notes/26.10/
Or, maybe, good name? They fight the good fight, even if they're not winning.
Good from an open source perspective, for sure (though they have stopped fighting the good fight as much for practicality), but for a lot of Linux users (namely: companies), that good fight is of no real consequence, unfortunately.
Historically, Debian didn't ship proprietary wireless firmware in the installer (because it was proprietary software, and Debian doesn't do proprietary), so you couldn't install it on most laptops without plugging them into wired Ethernet to download the wireless firmware packages from non-free.
They changed that a few years ago, but plausibly the underlying prioritization of end-user experience is still lower than Ubuntu's degree of user focus.
I still wish Mark would rename his company "Ubuntu". He's a great guy, the company does great work, but I keep getting undeserved credit for it because we wouldn't sell him the domain name.
For some reason I had feeling that Ubuntu more "serious" than Debian. I mean they're asking for money from people. So it's basically Debian with paid services. Can't be worse than Debian and probably is better, maybe they paid some engineer with these money to patch things faster.
That's just some rough reasoning in my head.
Also when you install third-party software, 100% of them will support Ubuntu. That's more about workstation usage, though. But having tested platform matters.
ahh, but this post just proved that it CAN be worst.
How is the gaming experience on Debian? I'm genuinely asking, not a snark.
I use desktop Ubuntu because it's up to date and it just works for me, and I can play the latest games in it with Steam + Proton. I don't have to tweak it or do any additional downloading of stuff besides the Nvidia drivers (I actually don't remember how I installed them).
Can I do this with Debian, in a no fuss way? (I know this can be done in any distro, that's why I'm stressing "no fuss").
Not bad. Steam/Proton keep themselves updated. If you rely on Wine from the repos, you might be in for a bad time, but Heroic/Lutris/Bottles in Flatpak stay updated. You mentioned Nvidia, but amdgpu has a repo that should keep things reasonably up-to-date: https://instinct.docs.amd.com/projects/amdgpu-docs/en/latest...
For some games like WoW I use Faugus on Ubuntu. It ensures I always run the latest and greatest Proton-Wayland.
But this is the thing I appreciate about Ubuntu. I know my LTS is from 26.04. I know all my software (with specific exceptions) is backported from that. The previous LTS were 24.04, 22.04, etc. With Debian, I won't know these out of my head. Partly cause I am into Ubuntu, but also because it isn't opaque. I mean, I don't remember from which time Potato and Woody were (but I used to run both back in the days). With Ubuntu, I remember (the codenames of Ubuntu I forgot).
Rest of games, Steam handles. I'm hooked on their ecosystem, kind if for a similar reason as Ubuntu (loyally sticked to them). As European I'd prefer a European gaming distribution platform, but Steam is just good and a fair netizen. Linux-friendly, too. I own a Steam Deck, too. Only reason I'd want non-Steam is all these free games I got on GOG/Epic/Amazon, and maybe some good ol' emulation.
Nvidia proprietary drivers are generally pretty old. I did some messing around with the CUDA packages to get recent desktop drivers in order to run some games.
Right? Can I install Debian and have Steam work as well as Ubuntu? Can I install Debian over my Ubuntu (without pain) and keep my dual boot with Windows 10 situation? If yes to both, will consider!
In my experience, Linux distros on older kernels sometimes struggle with modern hardware. Especially with newer devices, features and especially bug fixes take a while to make their way to the distro.
I believe Steam just works as long as GPU drivers are working.
On Arch I just installed the flatpak and didn't think about it, everything works.
I didn't have any issues setting this up in Debian
I find major version upgrades a lot more reliable on Ubuntu. Every time I've done that on Debian something big broke.
If your infrastructure doesn't use landscape, kernel hot patching, JuJu or similar Canonical technology, or doesn't have its own Snap storefront, there's no need to install Ubuntu. Rest is just momentum.
Debian used to move a bit slow in terms of userspace, and that's true, but for servers, that's a non-issue for the last 20 years or so (from my experience).
On the Desktop side, Fedora and Ubuntu moves faster on the userspace front, but if your system is behind a NAT, and you know what you're doing, Debian Testing is just as good, more stable and it's rolling (except when it's feature freeze, but a stable workhorse is better than a shiny but breaking one).
Debian allows me to sleep well at night, provides guaranteed updates, and works rock solid all-round, so I won't be touching Ubuntu for the foreseeable future. Esp, with controversial choices like uutils, etc.
Snap is a liability, not a feature.
Agreed, this fixes it for me on my machines:
cat /etc/apt/preferences.d/nosnap.pref
Package: snapd Pin: release a=* Pin-Priority: -10
I don't think we disagree a bit.
Debian doesn't have any of the Ubuntu Pro features, e. g. Kernel live patching.
Even my corp doesn't have Ubuntu Pro, I still have no clue why they use.
Has Ubuntu rolled out the patch only via live patching?
No, it's still WIP.
So their live patching is a larp too. Security theatre, pathetic company, pointless existence.
Look dude, let's get something straight: just because someone didn't jump on command for that one patch you suddenly care about out of the blue, doesn't mean they're LARPing on anything.
If you want to dismiss other people's work like that, have at least some decency to provide a track record beyond "they didn't do what I wanted REEEEEEE!!!!" type response.
No.
I would need to reinstall OS on my laptop and deal with all time-consuming migration stuff for everything that changed and to configure Debian where it is doing weird things
> What is Ubuntu offering that Debian doesn't provide?
I have it right now at zero additional effort
This is now trivial with agentic tooling. I recently used a separate laptop and VM over a weekend with an agent to complete a full migration. Cost is hours and a dollar in tokens.
I am not trusting LLM to let them handle backups and my critical infrastructure.
And I am not letting LLM to send contents of my private files to LLM providers.
Define these terms because it is trivial to mitigate.
LLM can define backup job, write scripts and configs.
AI connects to blank system, builds out config and then creates scripts to run rsync.
The way some people fear AI is not realizing that it is doing the operations.
> LLM can define backup job, write scripts and configs.
I still consider necessary to test and understand my backup system, so it will take nonzero time.
Proprietary drivers, desktop first experience similar to how Mandrake used to be, or SuSE, and the most relevant, in regards to proprietary software on Linux distributions, it tends to be either Ubuntu or Red-Hat.
Speaking as somebody who stayed on it way too long (until 10 years ago, maybe) it was because people constantly told me scare stories about how difficult it was to configure into something usable.
I had to go through the torturous path of Ubuntu -> Mint -> Mint Debian -> Debian. The last step was after I used a Debian live disk to do something and I could see that the stories were nonsense; just something that had adhered to the word Debian in my mind through repetition.
The two worst parts about it were 1) that I had long left Ubuntu on servers and had been using Debian there for years - I was just afraid of the desktop for some reason, and 2) that if I had just listened 15-20 years ago when people told me that FrankenDebians were nothing but problems, I would have never been caught in the net.
I've never been a fan of Ubuntu's business practices, but I'm just generally not into Debian derivatives anymore. If I were to leave Debian, it would be for an entirely different (and philosophically different) distro. I probably make an exception for Devuan, because it's only trying to change one thing (that I think of as the biggest threat to Linux, the final boss evil spawn of RedHat.) Devuan is an escape hatch for when the rugpull happens.
For servers, livepatch, latest ZFS and ZFS-on-root supported ootb, faster release cadence
For desktops, gaming and commercial software support, "it just works" (my fresh install of 26.04 with Wayland, recent WiFi, HDR+VRR, i didn't have to fuss with anything)
For laptops, I've routinely had issues in the past where Fedora or Mint wouldn't work ootb when Ubuntu did.
And then since it's what I'm used to on my server and my desktop, i just use it on my Pis and WSL installs for consistency.
I still try out other distros occasionally and i do run Debian on some specific VMs for various things, but I've just had relatively few issues with Ubuntu, been using it for >10 years, and don't see any reason to switch.
At my company, it’s the pateena of “enterprise”. I came to th company with strong open source bias. The more traditional/conservative IT guys were all about Microsoft and RedHat. When I lobbied hard for some Debian assets, Canonical was the compromise. But I think we’re real close now to seeing the next round of allocations be straight Debian.
> What is Ubuntu offering that Debian doesn't provide?
I'm on an nvidia jetson which comes out of the box with Ubuntu pre-installed (it's slightly more complicated but that's the gist). You can run other OSes but it is a messy experience and you can easily run into problems.
Yes, it is shitty from nvidia that they do it this way. But it is also convenient.
It's just the default target. For backend stuff, you're right that there's really very little true value. But client software just has a lot of complexity. If you run binaries from wherever, they're probably built and tested on Ubuntu first. Like, your vendors won't support distros officially, install scripts and AppImage integrations are going to tend to assume stuff. Driver/runtime integration for things like binary GPU stacks are going to document Ubuntu first. If someone makes an assumption about Python version (a personal peeve -- LOTS of python software ends up lagging the tip, it's not a super compatible ecosystem), it's going to be that you're running Ubuntu LTS version "one before latest", etc...
Are those fatal flaws? No. But lots of people just don't want to deal with it. And there's a market for that.
I can't think of anything I've ever had trouble running on Fedora + containers, with the latter typically for proprietary software that depends on specific or ancient userlands, or simply to avoid cluttering up my base system.
You can't put a driver stack in a container. You can't put container stacks (c.f. Docker, Snap, Steam, Flatpak) in a container. Containers can't by default do oddball hardware access for oddball stuff like flashing firmware for your keyboard or 3D printer. You can't reflash your motherboard BIOS from a container.
The fact that your mental model of running your foreign Ubuntu software is "in containers" tells me you're probably mostly running backend/cloudy stuff. And yeah, that's largely a solved problem thanks to Docker (and for the same reason, "Dockerfile" is now a standard platform that everyone integrates and documents for by default).
Again, it's not like this can't be done from other distros, it's that it's fiddly and the instructions and defaults are all going to be for Ubuntu LTS.
I used Debian on my machines (after I got past their ideological view on drivers and found I could get them separately and made it work) ... until a patch came out and WiFi was broken on my machines. I went back to Ubuntu, have not had issues like that. Ubuntu works reliably, from my experience, on real world machines.
Ubuntu did what Debian failed at. Better LTS, More features including drivers, available by default by most providers, lot more branding/documentation and in the early days, easier distribution. I am old enough to remember distro like SuSe Linux etc and when Ubuntu came on scene, it became the de facto.
Debian's modern release cadence and optional backports seems to have turned this around, to a degree.
I moved all my new server/service deployments back to Debian around 2021/2022 (bullseye era).
Just that it’s already installed, and I haven’t tried a new distro in over a decade.
But 15-20 years ago it was easier to install the nonfree stuff on ubuntu, like drivers and DVD playback and stuff. I don’t know if its still like that.
I never understood ubuntu as a server over debian, but for a desktop it was a nicer experience for a while.
It's the default for my VPS provider
They test run a little more tests on their backports (and have the manpower to actually look into what is failing) and they have really far out EoL once the kernel release is selected at fixed intervals. So if you managed to get the capabilities that you care about in their tests, there is a low probability that applying updates will cause some catastrophic outage or data loss over the next 10 years. Which can be improved further by fine-tuning phased update rollouts.
Unfortunately, they did in recent history manage to still break iptables, zfs, nilfs and a bunch of machines with weird (arguably broken) firmware anyway, so my personal comparison between Debian (or simply directly the Kroah-Hartman/Levin stable upstream) and the Ubuntu backports is not exactly in favor of Ubuntu.
I always assumed the software is newer. You can update to a LTS more often, if your server needs that. For example, I think podman adoption is hampered by Debian's slow release cycle. Trixie finally supports quadlets.
Debian often ends up as Frankendebian, or with custom repos added. How do you run e.g. Nextcloud on Debian? Where do you get the new php version required for the upgrade from? Right, there is a community repo somewhere...
I should mention this is maybe not an issue for servers with containers, nowadays. And desktops have marketplaces and linuxbrew.
But it took 3 years from Debian 3.0 to 3.1, then 'testing' was frozen for 2 years. A lot of users were lost to Ubuntu at that time, which released every 6 month.
In my case, I started using Ubuntu like 10 years ago because the desktop experience was much more polished.
For example, the fonts and the font rendering in Ubuntu and its derivatives were noticeably better than on stock Debian/Arch/etc.
Debian by default has had ancient versions of stuff, and if you want third party software, Ubuntu has more mindshare so it was more likely to be tested - anything from graphics card drivers to Steam games.
It hasn't. Debian has releases every 2 years, same as Ubuntu LTS, and packages are up to date at the point of release.
and of all those patches, the ones that have staying power get upstreamed as Debian packages all over again.
[for clarity, I am not talking about servers]
When a non-technical person asks me “which Linux?” I recommend Ubuntu because it is about as gentle an experience as Linux is going to be. The install is friendly and the culture is less RTFM than anything else.
Those are the same reasons I run Ubuntu on my laptops that aren’t running Windows…I prefer low friction to arguable technical superiority. I’ve looked at other distros in the past and decided they weren’t worth the bother…To Me.
But that’s me, not you or anyone else. And my use case not yours or someone else’s.
> and the culture is less RTFM than anything else.
To this point, adding "on ubuntu" to a search gives me better tutorials.
How does that compare to, say, Mint?
Disclaimer: I run on Gentoo, so I genuinely don't know.
I don’t know because Ubuntu is good enough for me.
But Wikipedia says it is based on Ubuntu…so for me, it would be just a different set of personal opinions implemented for “reasons.”
And as a recommendation, Ubuntu is probably going to produce better Google search results when someone gets stuck.
Consumer-centric customizations and non-free package options. It’s somewhat akin to answering “How can I add stuff like OneDrive to Linux and not have to configure/self-host everything?”
I used to like Ubuntu and Canonical products and these days I’m more indifferent towards them. Their products have a place, but I wish Canonical would stop killing off some of the more interesting side projects.
I'm not a Linux user, but occasionally self-host some stuff. One time I tried Debian instead of Ubuntu, it was a lot of "this is not installed" & "this is not set up" errors during setup process of software I wanted. In the end I succeeded in doing what I wanted, but I also wasted time on doing things I never have to do when using Ubuntu.
But we're talking about running a server in production here.
If one can't be bothered to install what is needed, maybe one should not run a server in production?
Quickly running something on your LAN for testing is different, but if you expose it to the Internet, probably your main concern shouldn't be "this is not installed".
Parent comment asked why Ubuntu, I answered why (for me). There was no specifying on how big and what scale of production.
Large enterprise with multiple knowledgeable people on payroll have different concerns than small me.
MySQL. You can make a totally valid argument that sites should just switch to Maria DB instead, but there's also no doubt that dropping MySQL support from Debian cost it a lot of LAMP servers. That, combined with Debian's release cadence which made it difficult to run numerous PHP apps basically pushed LAMP servers to Ubuntu.
Familiarity. Many Ubuntu people(who were introduced to Linux via Ubuntu) never change horses. I am speaking about IT people not common folks.
You and I know Debian isn't much different, they don't know cuz some never investigated. I say some because they landed in a role with a company that is Ubuntu and never had reason to learn anything else.
ZFS.
Use the Proxmox kernel on Debian for that. That's what I do, and it's been great!
As I understand it, this is based on the Ubuntu LTS kernel, but doesn't necessarily rely on upstream's release schedule for fixes.
Given that most of the Proxmox userland comes from Debian Stable repos directly, it's probably not the worst idea in the world if you want to run ZFS on mostly-Debian Stable.
Oh, and while I'm not sure when the fix was applied, CVE-2026-98432 is patched on my Proxmox (no subscription, all ZFS including root) server.
I'm writing this on a Debian machine that is using ZFS. It's Red Hat that has a problem with ZFS, not Debian.
Are you using the vanilla Debian kernel? The advantage of Ubuntu is that you don't need to depend on DKMS for something as vital as a file system.
Yes, it's the normal Debian kernel plus DKMS. It just works seamlessly.
For desktop use, new-ish user-facing packages without any hoops (such as backports) jumped. Especially where collaboration is involved it can be a major issue when a program lags behind its commercial OS counterparts by several months or years in terms of features and behavior.
I don’t use Ubuntu but use Fedora (and its derivatives) partially for that reason.
>What is keeping people on Ubuntu instead of just using Debian?
1. It uses much newer packages and people want shiny
2. It was marketed as one of the easiest to use linux distributions maybe 15yr ago or whatever, so a lot of new people and then tutorials went to it because newer software and features just worked.
3. What is keeping them on it now? Familiarity. Inertia.
They probably don't know Mint was based on Kubuntu. Or that they all - like DSL, Knoppix and others are all based on Debian and if you're brave, you can pivot to Sid from each of them.
When I worked at Canonical, the funnel I observed was Gamer Culture and the Chronically Online. They don't know from Debian.
I only run Debian personally, but my dayjob company runs on SQL Server, and the officially supported options there are Windows Server, Ubuntu, or RHEL. It's not worth the effort dealing with management/auditors/etc. to try to run our prod DB on a non-supported platform.
Because every where you used to go on the internet you read that debian is “slow” on updates but stable as a trade off, if you are after certain new packages you have to use Ubuntu, also, some use cases (say jetson boards) have ubuntu by default plus nvidia drivers.
Ubuntu is the gateway drug to Debian, in a lot of ways. You get used to GNU/Linux with Ubuntu, then you find out that there are more refined options and go for those, and a not-insignificant part of that crowd likely goes to Debian because of how familiar it is.
Careful, lest someone's going to mention Arch.
I agree btw. But I've been using Linux since end of 90s (I barely made use of the 2.0 Linux kernel series). I quickly established on Debian in the Potato/Woody era. Debian, back then, was severely slow with new releases. So I ended up with Testing. Which got slower security updates than Unstable. Which sometimes broke (like any rolling release does). Back then Ubuntu got released (we talking '04 and '06). And I just sticked with Ubuntu. On servers, too. I endured it all, including the Amazon spyware, the ads in MOTD, and the switch to an inferior in-house software management for some package (which name we won't mention).
I think it's a good opportunity to remind those reading this thread that they need to talk to their children about Arch Linux before someone else does.
I know it seems innocent enough at first, setting up a system just the way you want it and learning a lot of Linux's userland internals while doing so, but before you know it you're installing esoteric window managers to get your theme just right and hunting for the perfect picture of an anime waifu to be your wallpaper, all while telling others that you "use Arch, btw". Always sad to see someone fall into that sort of life.
By Arch, you mean that wiki with tons of information on installing and configuring software on Linux, right?
Say what you will about Arch, its community seems to have a rare gift for writing useful documentation.
For me, habit. A habit I'm getting tempted to break by exactly the grumble in this post. This has been an awful ~two weeks for maintaining infrastructure and the ubuntu lag on this specific issue is contributing to the awfulness.
Their kernel is vastly superior when dealing with buggy enterprise hardware.
Would you mind detailing? I have never encountered that kind of issue, so I'd love to learn more.
any broadcom networking hardware, on debian it will constantly drop out @10Gbps link speed on copper is one such case that I can describe. But over the years there's been plenty of related issues with e810's and whatnot. Disks, disks will also stall or drop out which doesn't happen on ubuntu kernels.
Do elaborate.
vendor oem's shipping broken firmware, enterprise customers complain to ubuntu, ubuntu fixes it in the kernel driver
Enterprise support contracts for Linux and the compliance legal liability. No large commercial companies would run purely contributor supported systems because of the lack of those two things.
It's the default that a bunch of vendors package. For example, Nvidia's official CUDA images used to only be provided for Ubuntu (they have since expanded their offerings somewhat)
Desktop Ubuntu purely because of the drivers. Normally used Debian for my own servers, but haven't done that in so long, and Ubuntu is often default on cloud providers so yeah.
It’s the default offered by most cloud providers, so in some sense it’s pure inertia.
I really don’t care what I run on, as long as it’s some flavour of Linux, it works reliably, and it’s secure.
FIPS mode? It's a pretty niche requirement, but I was under the impression that options are somewhat limited for FIPS-compliant crypto (both disk and networking)?
Mostly:
1. Hardware generally just works
2. Videos that use patented formats just play without fiddling
3. Proprietary closed-source software, if they even support Linux, usually releases Ubuntu binaries before anything else
Back when I used Ubuntu it was because I was tired of being excited about a new feature and not getting to use it until it made its way to Debian 5 years later.
Suppose you are an enterprise paying large amount of money to NVidia to buy their AI hardware to run AI workloads locally. Are you going to say we will refuse the default OS (https://docs.nvidia.com/dgx/dgx-os-7-user-guide/introduction...) on such hardware and lose hardware support, or are you going to stick with the supported OS for your hardware?
Enterprises care far more about vendor support than the typical Linux hacker at home.
Software, such as AMD Vivado, tends to support Ubuntu more than Debian by testing against Ubuntu only. Nvidia's Jetson stack supports Ubuntu.
Ubuntu's remote OS upgrade feature exists and works pretty well in practice. I am not saying this is enough to stay but it does exist.
All my servers were debian until I brought some Raspberry Pi 5 boards. Debian still does not have tested images for them today.
Approx. two years ago I saw a teacher at my IT school trying to install Debian on a students virtual machine, side by side to a Windows 11. Just for fun, while watching them, I installed Ubuntu side by side on my virtual machine. These two were not done after three sessions and ultimately failed to install Debian. The installation GUI was full of cryptic words I never heard of and looked like from the year 2000. Meanwhile, the Ubuntu installation went flawless. it was done in under 15 minutes, the GUI looked modern and sexy. All I had to do was enter a nick and password, and drag a slider to tell the procedure how much space I want to reserve for Ubuntu.
I hope that answers your question.
How is that possible. You can just press enter during the whole install except the prompt for wipeing the HD where you need to select Yes do wipe it.
I dunno. Maybe things have changed in the last two years.
Inertia, I'm guessing. I have a couple of older on-prem servers still on Ubuntu LTS. Newer ones are on Debian stable.
ROS, which is not officially supported on Debian. Not using it myself, but users here do use it.
Please suggest a better alternative for a cloud server? (Genuine question, where do I move?)
AFAIK with Debian you remain on older versions of packages (unless you are on Debian testing).
Exactly like with any Ubuntu release. Ubuntu is a clone of Debian.
Ubuntu is based of Debian testing. You can verify this by comparing the versions of neovim available on the repos.
Debian[1]:
> trixie (stable) (editors): heavily refactored vim fork
> 0.10.4-8: amd64 arm64 armel armhf i386 ppc64el riscv64 s390x
> forky (testing) (editors): heavily refactored vim fork
> 0.12.4-1: amd64 arm64 armhf i386 loong64 ppc64el riscv64 s390x
Ubuntu[2]:
> stonking (26.10) (editors): heavily refactored vim fork [universe]
> 0.12.4-1: amd64 arm64 armhf ppc64el riscv64 s390x
I use Debian stable myself and build neovim from source for this specific reason.
[1]: https://packages.debian.org/search?keywords=neovim
[2]: https://packages.ubuntu.com/search?keywords=neovim&searchon=...
AFAIK Ubuntu still ships newer versions. Maybe this is just because it ships new distro versions more frequently, but the end result would still be having newer packages on the latest Ubuntu release vs the latest Debian stable. I'm not an user of either distros though, so I'll wait for someone that actually uses them to confirm/rebut.
I have a company laptop that came with Ubuntu from the factory, Debian wasn’t an option.
If you ask I'm sure they'll let you install Debian on it.
much newer software, kernel, default setup is much more user friendly
Paid support. Doesn't look like it's worth it, though.
1. Faster and predictable release cadence. New releases every six months, April and October (hence x.04 and x.10). New LTS releases every April on even years (26.04, 28.04, 30.04, etc).
2. The LTS releases are supported by Canonical for at least five years on the free tier, and up to fifteen years with paid support contracts.
For #2, they are clearly not "supported" in a timely manner if we're waiting 2+ weeks for a patch.
You can argue that Canonical isn't upholding their end to provide security support, exactly what TFA is all about.
It's still a pretty basic reason businesses might calculate that Ubuntu is a good fit.
Agreed. Two weeks is pathetic. But, yes, I went over to Ubuntu because they were supposed to provide five years of security updated.
When I interviewed with them a couple of years ago, I got the sense there was a lot broken with their culture. It was the best choice back when RedHat/CentOS stopped providing long term security updates, but now that Rocky Linux is around, it’s getting to be time to jump ship again.
Also, almost every other time I upgrade Ubuntu, it's a shit show. I've seen the renaming of network interfaces, loss of default routes, systemd jobs that take several minutes to timeout... It's like rolling the dice. All the problems were fixable, but still an annoyance.
More recent packages
"Ubuntu" is an ancient Swahili word meaning "I can't install Debian".
Over the years its meaning has drifted to mean something like "I won't install Debian". It's easy now!
I use it as default for WSL2, because it's a default
They have more kernels, more support for modern hardware etc... good luck running Debian on a modern laptop.
Ubuntu kernels are not the one that Debian uses. The latest stable Debian is based on a 2 years old Kernel ( 6.12 ).
"Ubuntu" is an ancient African word meaning "I can't configure Debian."
If it's a corporate computer you don't want to deal with manually configuring stuff. I also want as little manual configuration on my personal machines, hence why I use Ubuntu.
Debian's ancient packages and kernel.
Increased safety with Rust utilities. /s
On the desktop, Debian is pretty weak.
What software can be used on Ubuntu but cannot be used on Debian?
Just because I can reconfigure the entire OS to work on my computer doesn't mean I want to
I think you're mistaking Debian with Arch.
It just has package for nvidia drivers. Not sure if installer will install it automatically for you (I kinda... use my install for last 12 years, just upgrading it).
For me both with AMD and NVIDIA whole hardware driver story was "install it, it works"
I'm referring to the ubuntu-drivers thing. You can do the equivalent in Debian if you add non-free repos and find the right packages, it's just more hassle. But if all you need is GPU drivers, no need for that tool.
At least Debian is on Wayland. Mint is on X11, which was causing black screen out of the box on my fairly typical PC.
I suspect many new users get confused by the fact that lots of Nvidia hardware works poorly out of the box, rather than not at all, where the latter would at least provide a clue that a non-inbox driver might solve the problem.
To clarify, the Mint/X11 issue isn't that. I had the Nvidia drivers. X11 had some issue with graphics switching. It worked fine on Wayland.
They kinda need a basic working driver just to make it easy to install the good driver.
Oh also, last time I used this was years ago, and I'm willing to try Debian next time I use desktop Linux now that uh things have changed
>Oh and btw, distros run by volunteers (Debian, Arch, Alpine...)
And Slackware too:
From: https://ftp.osuosl.org/pub/slackware/slackware64-15.0/Change...Slackware is a cool distribution. I really love that it's maintained by Patrick and I enjoy the simplicity and the stubbornness of it's opinionated decisions.
I stopped using it back in 2004 when Patrick had health problems. It seems to be a passion project and it stopped getting updates while he recovered. There is a community behind it but it may mainly be driven forward by him.
It looks like it's fairly slow to get updates, generally, as the last release was Slackware 15 in 2022. Maybe that reflects it's dictator (his word not mine) or maybe it reflects it's stability.
Yet, despite all that, Slackware got this security fix around 10 days ago.
Slackware-current or slackware-current64 is the main release channel. https://mirrors.slackware.com/slackware/slackware64-current/...
There's dvd iso's available the slackware-current branch, usually built about once a week by AlienBOB
Guess you could call it a passion project, but after all these years of dedicated tireless work that seem to resemble more of a machine than man, seems that doesn't completely sum it up. Hope he keeps it up, its pretty much the only pure distro left (or maybe I dislike systemd that much)
Slackware is basically a rolling distro in all but name at this point.
You get a very different CVSS score depending on the formula you use. Ubuntu's response page lets you select between the two.
(I think CVSS is a very poor metric in cases like these; I'm just explaining what I think Ubuntu's process/position is, not making excuses for them. My read is the 9.8 is probably too high but nevertheless more accurate in this case.)
I moved over to Debian and haven't looked back, years ago. Why anyone would prefer Ubuntu over Debian, which is a purer, higher quality, more mature distro, is beyond me.
> Why anyone would prefer Ubuntu over Debian, which is a purer, higher quality, more mature distro, is beyond me.
For me, I view Ubuntu as the "higher quality, more mature distro" which I value over "purity".
You can argue about quality I guess, but how would Ubuntu be ‘more mature’ than Debian?
Ubuntu (and Kubuntu) have never bricked all of machines after an update, Debian did, in recent years at that. So I will argue quality in favor of Ubuntu (and Kubuntu).
Your view does not seem to match reality, as shown by this story.
There is a reason I moved to Debian; it is not like I just like the sound of it better.
My opinion of the story is that it is over hyped, with my hunch being it's possibly to throw free advertising towards Anthropic, though I have no proof of that, just my personal intuition based on the handwavyness of the story.
My view is based on having used Ubuntu since 2006, Kubuntu since 2023 or so and a serious stint on Debian until they put out a patch via regular updates that bricked my machine's wifi (all of them). So my view is based on real world experience and your comment "Your view does not seem to match reality" doesn't seem to take my experience with Ubuntu and Debian into account.
Well, I did it. This was the straw that broke the camel’s back: I have moved over to Rocky Linux. Took me maybe four hours to do the full transition.
I am more a RedHat user, and Ubuntu never felt really comfortable for me. I don’t like having to do incremental upgrades every two years or so; I would rather do a single big upgrade about once every 7-8 years and have a rock solid development environment. Also, `dnf` is simpler and more stable than the mess of `apt-get` and `unattended-upgrades`.
> Also, `dnf` is simpler and more stable than the mess of `apt-get` and `unattended-upgrades`.
I'm not saying you're wrong. I am saying that this is a new sentiment I've never heard expressed before. Perhaps Ubuntu's done something to make it flaky, but the upstream Debian apt tooling is famously stable and boring. I'm saying this very seriously: I don't recall a single time, ever, in about 30 years of using Debian-and-friends, that I've ever been bitten by a bug in apt-get or apt. I have also never been hit with a dependency bug when I wasn't using dodgy third-party package sources. In the many situations where I've deployed pure Debian (or pure Ubuntu) servers, `apt update && apt upgrade` has worked 100% of the time.
I do not claim that no one's had problems with this. The world's large. I'm certain there are people out there who have nothing but trouble with apt and friends. I do claim that I've never personally seen that our been in a conversation with people who have.
`unattended-upgrades` was frequently giving me Python warnings in Ubuntu 24.04 about how `fork()` should not be called. `apt-get` has given me issues, years ago, where it would pull up a crappy full screen text UI asking me (usually irrelevant) questions about some update it was doing, and the entire update process was halted by those questions.
Worth noting that RHEL, the Linux version Red Had sells licenses/paid support for, also didn't update it for weeks
I found the linked Bloatberg article very funny. https://bloatberg.com/2026/11/02/ubuntu-canonical-extends-lo...
They haven't patched pwnescape either, which is like 15+ days old - allows for KVM breakout.
https://ubuntu.com/security/CVE-2026-99999
Did Ubuntu Pro customers get the fix?
I have one Ubuntu Pro server and it has not received the fix yet. Fedora would have been preferable but that is "not supported" and I had to have Ubuntu.
RedHat didn't patch anything neither, it doesn't matter.
It does matter when it comes to which OS I would prefer running.
I think this is the important question. To everyone who is complaining while using Ubuntu for free: People whose software you use for free don't owe you anything.
Of course they don't owe them anything. Ubuntu's reputation is built primarily on people who use it (or used to) for free. They are/were Ubuntu's advocates and what made it popular.
So just as they made it popular, they can make it unpopular. People like me will simply post on our blogs and social media that they should not install Ubuntu. A typical Ubuntu user is not that high on the tech scale, and they listen to people like me for suggestions on which distro.
Cut the pipeline that feeds into it.
Ok, but in this case it also isn’t available to people who pay.
Apparently they don’t owe anything to Ubuntu Pro subscribers too.
Nope
I've switched my default to AlmaLinux. Was a fan of Ubuntu since 8.04 (Hardy Heron) but stopped since Canonical pushed hard on Ubuntu Pro.
I don't like ads, and I didn't like logging into SSH and seeing a nag to update to Ubuntu Pro because I had the balls to keep running 20.04 in 2023. I've seen this before on previous releases (and know how to remove the message), but seeing it again was the straw the broke the camel's back.
It’s basically Windows at that point!
AlmaLinux is "boring" in the best possible way, and it works really well in WSL too. Their extended support for x86-64 v2 has also been useful on one my old computers.
This is the straw that broke the camel's back. I am moving back to Debian stable now. Having NVIDIA drivers and Wlan drivers back in 2014 was great, but this is not acceptable.
I have had some thoughts about switching to Fedora for my daily driver laptop - but as far as I can see I would not be better off in this case with Fedora? I cannot see that they have shipped a fix for this either?
I think this is more of a communications failure than anything. My understanding (happy to be corrected) is:
1. That for this to be a DOS type exploit, the attacker needs to exploit a race condition over network, which is an incredibly unlikely event that one can't really force.
2. For it to be a root exploit they need to craft the IP options with a specific memory address, but that memory address isn't known to the attacker because it's not a constant (see KASLR).
3. There is also a simple fix by simply adjusting iptables, and much/most/many network setups already drop IP options by default.
If I'm misunderstanding something let me know, but in practice this doesn't seem like it's likely to cause much damage. The people at Canonical and Redhat probably came to same conclusions and are balancing the true risk (not CVE risk level which are not very useful) with the potential for introducing a regression for their customers. This kind of stuff happens somewhat often and never catches fire like this, I think Anthropic is just fanning the flames and Ubuntu is taking the heat.
Revision: It seems like catching the race condition is not that hard, but the root exploit is very unlikely. But still, the fact we haven't seen lots of services going down indicates to me that this is overblown.
E.g. Ubuntu 22.04 Linux kernel 5.15.0-203.213 was published in Canonical's proposed kernel PPA on October 26, 2026. So just enable Canonical's proposed repository, use APT pinning to prevent automatic installation of untested packages and install the patched kernel. I agree that they need to get quicker at pushing these updates into stable, but it's not as if you don't have a choice.
Same with the recent PHP vulnerability Debian had the patch ahead of time. Ubuntu had it many hours later...
The bad news is that Canonical is slow to fix critical issues. The good news is that Canonical is full of people with exceptional SAT math scores.
The "WTF" is unwaranted, it's really not that easy to write a weaponized exploit for a bug like that one.
I am a bit surprised by the panic...
I'm not too surprised, it feels more like a way to help promote Anthropic than what it tries to appear to be.
It's really not that easy - for a human - to write a weaponized exploit for a bug like that one.
No, I'm pretty sure AI too can't write an exploit for this, forget it about a reliable one.
Its only the media / publicity that drives this one, there were worse within the last year that nobody seems to care about.
That is with the implicit assumption that the mptcp exploit of this ipv4 tcp bug is the only exploit that will be found. I don't think that assumption will hold true.
There were other fragmentation flaws that were equally as bad as this, I wrote the reproducer.
IIRC it had minimal HN discussion.
The takeaway -- prefer Debian over Ubuntu for my servers.
A nation state actor behind a popular linux distro got discovered with keys to the kingdom and they scramble to keep their option open, while acting as if nothing has happened - that's how I see it.
I have been thinking of moving to NixOS from Ubuntu. Are they any better on security updates?
Yes, NixOS has already patched this.
NixOS also makes it much easier than ubuntu to install your own patches and version of the linux kernel.
For example, assuming NixOS had not yet released the fixed linux version, 6.18.56 (though it has), you could upgrade to it before NixOS did it upstream with this one line:
You could add the patch yourself if you needed to with: And then you'd be updated.The debian and redhat based distros all make it so configuring what packages are installed ('apt install' / 'yum install') is a different operation from configuring the packages themselves.
On NixOS, the specification of how to build a package, what package is installed, patches, etc are all in the same language, and so it's a lot more natural to patch things as needed.
And also, LLMs are pretty good at generating working nix, so you can have an agent apply patches to your kernel package with NixOS quite easily. Agents can also do this for ubuntu or redhat, but in my experience they're much worse at it, and it's harder to undo mistakes if they mess up.
Substantially worse in my experience. They build the whole OS in CI which is slow and unreliable, and as a result it can take 2+ days for updates that other distros have out in under an hour. You can try mix packages from smash or unstable builds but for stuff like kernels that’s not simple.
The quantitative data we have shows that NixOS is fresher than other distros in general by a significant margin.
See https://repology.org/repositories/graphs
If you pick a specific random package update, nixpkgs often has that update months to years before other distros.
If you pick a specific CVE, nixpkgs usually is better with the exception of embargoed ones, where Ubuntu, Fedora, etc get to prepare their patched packages ahead of time.
NixOS is often far behind when it matters. Not this time.
> They build the whole OS in CI
As opposed to only building a part of the OS?
As opposed to building a single package in isolation.
So if the Chromium build runs out of memory on the CI node 3 hours in, then you don't get your linux kernel update.
(~10 years NixOS user, and committer.)
It depends.
Mostly on how much rebuilding it needs (e.g. if it's a "leaf" package, or one many packages depend on).
The merging of security fixes is usually very good, also because it is so easy for anyone to just make a PR.
The security team also seems pretty competent and fast.
As a sibling commenter says, it is also extremely easy to just apply patches to your own system in general, usually with a few line of easy code max. So you can fix systems without dependence on distro maintainers.
In contrast to e.g. patching a `.deb`, you can declare the code such that the patch will still be used even if the distro releases a new package; you can carry the patch forward, and don't need to choose between {not having the patch because the distro lacks it} and {not having future security fixes because you pinned your custom .deb version}. NixOS will rebuild any future update, applying your patch to it. That's a big benefit, because it makes "out-of-tree" custom patches very maintainable.
Due to declarativeness, you can easily roll out your fix on lots of machines.
Also, the "SBOM" (software bill of materials) part is quite good in NixOS. It's very easy to determine which package uses what dependencies.
The only real drawback is CI build time when a high-dependency package needs fixing.
Due to the way Nix works with its immutable hash DAG of package dependencies, a package change will trigger a full rebuild of all packages that recursively depend on it.
For example, if you change 1 line in glibc, or libpng, or curl, or (recently) brotli, the entire distro needs to be recompiled from source ("rebuild the world"). Some of the packages, such as Chromium, can take many hours to rebuild individually. Rebuilding all-of-NixOS can take days.
In distros that can mutate packages without triggering dependency rebuilds, updating 1 line in e.g. glibc, will only rebuild that package, allowing to theoretically distribute such security updates within minutes (if done, see Ubuntu counter-example).
The mass-rebuilding is done by NixOS's binary-cache build farm. A new NixOS update is generally only released once the build farm has fully built all dependents. (One can also opt into a "small" channel that releases as soon as only a few core packages are built, which gives you security updates faster for those. But if you do that, your computer will next start compile all huge packages such as Chromium, in parallel to the NixOS build farm already doing that. So usually people don't.)
For the recent brotli CVE-2026-111497, the timline was:
So in summary: For our startup, I rebuilt the slice of the world we use on a 16-core CPU within a day or so, without waiting on the NixOS build farm to build all of NixOS, so we got the update significantly faster.Also note that just patching a library in your distro is often not enough. For brotli, lots of upstream package vendor brotli's code. NixOS contributors seem to be quite good at looking at underlying issues, e.g. there's this issue "Tracking vendored Brotli decoders" (https://github.com/NixOS/nixpkgs/issues/578375) to track that. I am not aware of other distros making such efforts.
Thus:
In NixOS, security updates are great and fast for leaf packages such as the kernel, but can be slow for many-dependents packages. Much of that can be mitigated by building things yourself, which is easy.
Hope this helps.
This is a valid concern.
AI is now capable of, and being applied to, find so many bugs recently that infrastructure providers need to up their game and respond quickly.
Hopefully this is a passing phase as bugs are quickly patched, and we'll get past it without too many incidents.
On desktop, Debian stable has been excellent as of Debian 13. Ubuntu was good until 2018, and has since been sluggish and slighy buggy.
I highly recommend Debian. Breath of fresh air and freedom, compared to windows and MacOS.
+1, switched to Debian with 13 since it got plasma 6 earlier. Much better experience- no snaps, gnu utils, stable. It's everything I want from the OS.
I cannot express how stable, secure and butter smooth Debian is for servers. I don't regret sticking with it for so long
For people who absolutely need to run 16.04, 18.04 and 20.04 without any further subscription, I recommend installing the signed kernel from 22.04 (as of right now only available in the -proposed repo). Worked fine for some 16.04 examplary machines I had around that are stuck and bumps the kernel to 5.15 (soon EOL, but maintained by ... canonical, to get security patches).
For me, installing newest Ubuntu mainline kernel did work:
https://kernel.ubuntu.com/mainline/v7.3.1/
It’s not a good look that Ubuntu is taking its time with this patch even for paying customers, but I do have to question how widely exploitable this is. If your site is mission-critical, it most likely has a load balancer or reverse-proxy in front of it that’s probably already filtering it out. Companies like AWS have already confirmed that their load balancers filter it.
Remember that the AI companies benefit from creating panic every time there’s a new security exploit.
I'm switching to Debian for my companies and personal projects.
For 15 years or so, I used and recommended Ubuntu. But this is unacceptable and I won't be looking back.
What would you recommend to use on servers? Would you host you apps off Arch? Or better to take Fedora or similar? I am genuinely interested in answers not distrowars
After painful Ubuntu upgrades in the past, I moved to Alma Linux and have been very happy. It takes a small adjustment to dnf instead of apt, but realistically I was over that hump in 30 to 60 minutes and this was before AI. With AI to translate and test install scripts and the like, it might be a 5 minute task depending on how much automation you already have in place. Though even an entirely un-automated setup that is just a README.md, claude wrote me an Alma Linux version of a very ubuntu specific project that gave instructions for Alma instead of Ubuntu, and it worked almost perfectly first time and AI was able to (with prompting) see the issue and quickly found a workaround. We're a small org, but at some point when we hit scale and have compliance requirements, a migration to RHEL is also largely trivial if/when the time comes.
Good question... I run ubuntu on servers because the LTS has clear 5 years of security fix.
I use arch linux for my NAS because it's fun and I don't care if it occasionally goes down but I wouldn't use it for production (on my NAS it's mostly stable but has gone down a few times)
So what's next? Centos is a rolling upgrade, nixos?
As always, it depends on how and what you're managing on it.
VPS/VM? Debian is a great choice. Use it as base and run your software via systemd+podman if you want the most up to date stuff, Debian tends do lag a bit. It is very low maintenance.
Bare metal? Fedora Atomic is awesome. It does require an update every other week since it keeps packages closer to upstreams, but this is where the immutable base shines, any issue is an easy reboot to revert. Also systemd+podman for your own software.
I wouldn't recommend Arch on servers.
Edit: clarified Fedora immutable spins are called Fedora Atomic.
Note that Fedora CoreOS is a very low maintanance atomic Fedora system designed with fully automated updates in mind, and along with the systemd podman integration you mention, can easily be set up to automatically update both OS and containers.
Which may not be ideal for serious production workloads, but is perfect for non-mission critical appliance workloads like Pihole.
I use Arch for servers too, for almost a decade, and to my memory only once I had an issue. That was booting off an encrypted RAID and some change which needed some investigation and then reconfiguring. I am planning to run them servers on Arch for as long as I can. It’s a bliss to never upgrade my system (only update it).
Similar. While theres something to be said about declarative and immutable distros, if you're not going that route a minimally opinionated distro works a treat for server workloads.
And besides, just about every workload you can containerize should be containerized. Ideally though many with more isolation than what plain old runc provides.
I like Alpine but I’m not a serious person.
Debian stable of course.
> ...distros run by volunteers (Debian, Arch, Alpine...) have shipped the fix. Meanwhile Ubuntu, made by a company that sells security subscriptions, hasn't.
This tells you all about the priorities of companies. It's making profit, not protecting their users. Perverse incentives and all that.
If anyone is moving away from Ubuntu, I suggest NixOS, especially with LLMs. You will be able to build the machine of your dreams.
This is like switching from a bicycle to a TARDIS. With all the upsides and downsides.
It is strange, agreed. I just manually mitigated it using Claude and also blocked ipoptions at the router and in every node iptables.
I genuinely want to understand why people use Ubuntu, and especially for servers. I’m not trolling or whatever the proper word for it. It’s not sarcasm either. I must be missing something, I guess. What is the reason? Especially if you’re not paying for it. But if you’re paying for it, I’m still curious.
It was like that when I got here. The servers at my work were all Ubuntu, so that's what I keep using. And if the servers are Ubuntu, I'll use that on my machine too.
the best answer to this is... why not?
I also ran into this problem. But it's possible to install an untested Linux kernel, and that fully solves the problem. As for Ubuntu — yes, it's terrible. Fortunately, there's a workaround.
These recent burst of major security issues really have shown that paid security updates from the likes of Ubuntu and CloudLinux really aren't worth the paper they're written on.
Should we also talk about the snaps when trying to install package in Docker image (such as chromium-browser)?
I keep Snap disabled on my systems:
cat /etc/apt/preferences.d/nosnap.pref
Package: snapd Pin: release a=* Pin-Priority: -10
This turnaround time is appalling, especially given that Debian shipped a fix weeks ago. Poor show, Canonical.
Debian is already on 6.12.115, the stable kernel from 3 days ago. Who knows what horrors were fixed?
Maybe they got a bribe from some intelligence agency to leave it open a little longer.
OpenBSD got a recent GeFS (COW FS, but far lighter than BTRFS and not to mention ZFS) update, I wish 8.1 or 8.2 had it stabilized, because the issues with FFSv2 would end in the spot and maybe even steal some server machines to GNU/Linux.
sudo sysctl -w net.mptcp.enabled=0
This is misinformation.
The Anthropic PoC used MPTCP, but the underlying bug does not need MPTCP to be enabled.
From the same company that demands high school transcripts and club affiliations for engineers 20+ years out of high school.
Creepy as hell company. Had a good free Linux distro, but it's not that good anymore. It's coasting on inertia these days.
Interesting. Given the tone you must use MPTCP with options. Hardly anyone does.
There seems to be something off about this post. One hour in and hundreds of comments.
Either this was used to pop something big, or this is a jia tan situation going down.
I thought there was a flamebait automation that was prevent this sort of velocity (unless overridden)
or maybe, just maybe, entertain for a second that upstream (linux kernel) shipped the original patch commit on October 1st with rollout to mainline on October 9th and disclosure on October 15th.
People with affected systems have been waiting ever since for canonical to ship ... something, anything. Or maybe communicate the blockers. Crickets, though.
It gets all the more egregious if you're a paying customer for Ubuntu Pro (which thank god, our company is not).
It is absolutely taking the proberbial piss when you put it into context of their bold shiny new ambitions posted on September 23rd on their official blog (https://canonical.com/blog/accelerating-delivery-of-cve-fixe...) ... failing every single listed requirement in that announcement, now 14+ days, after initial CVE disclosure.
No need for a tin-foil hat here at all. Ubuntu has a large installbase. Part of which hosts servers. And if I had to take a wild guess that userbase is about to shrink dramatically going forward.
People panicked about the issue can either apply a quick IPTables mitigation or install the kernel Ubuntu hasn't released to production yet. It's annoying that Canonical is late, but it's not the end of the world either.
Unlike Arch or even Debian, Canonical has dozens of kernels to test and verify. The downside of supporting your software for ten years across multiple chipsets and even offering in-between kernel updates is that you need to test and maintain a shitload of kernels. Testing all of those takes time.
I hope they do a write-up about what went wrong here but all the big companies were weeks late to the party. My guess is that some of the patches were causing issues when backported, or Red Hat would've released updates much sooner as well.
A colleague once told me not to use Ubuntu in production. I was too busy/lazy to research why. That was ten years ago. I'm glad I procrastinated in my research and just used Debian all these years.
There are a lot of Ubuntu boxen in production out there. It is basically the default for Linux VMs in Azure, the UX sort of pushes you that way unless you have a particular preference otherwise. I do have a preference, for Debian which I've used at home for many years, but in DayJob Unbuntu is close enough and seems to make others more comfortable (in part due to the impression some have that it is better supported in Azure). I'm surprised MS aren't nagging Ubuntu to pull their finger out for this reason (maybe that are, behind the scenes, but if so it isn't working).
> distros run by volunteers (Debian, Arch, Alpine...) hve shipped the fix.
Well - Ubuntu sold out to marketing rather than engineering.
Happened to Google too. Compare Google Search to 10 or 15 years ago. Totally useless nowadays.
Everything that's built by a publicly traded company is built for shareholders, not for consumer. Switch before it became unswitchable or learn the hard way.
Canonical isn't a publicly traded company
My bad. For now, they were just cosplaying as such [0] with anti-consumer decisions in the recent years.
[0] https://en.ubunlog.com/Canonical-will-go-public-this-year/
> According to Shuttleworth, the company is now ready to go public , something they attempted in 2005, but the conditions are now more favorable.
> meaning that some Canonical products will cease to be developed by the company.
So nice to see people coming back around to Debian.
Listened to over a decade of people chirping about the new hotness and calling my Debian servers lame, old and busted. Well look at you now!
Does no one remember Shuttleworth's underhanded deal with Amazon way back? That was treacherous enough to never look back.
I’ve always hated Ubuntu. I simply don’t understand the pitch as to why someone would use Ubuntu over just good ol fashion Debian. Better yet: FreeBSD.
Given that Ubuntu is downstream from Debian, I can't think of a single good reason why Ubuntu wouldn't just release Debian's patch.
> I'm moving all my servers off Ubuntu.
I wish life was that easy.
I migrated all servers off Ubuntu as well due to this and slow PHP patching as well. Now running a mix of AWS Linux 2023 and Debian.
I used to be a contributor to distros, but I found that Ubuntu simply has no method by which I can fix things and contribute them back.
Debian vs Ubuntu debate officially settled today!
I'm not finding a reference to CVE-2026-98432 on the stable updates mailing list or in changelogs for 7.2 series.
It's the first commit listed in the 7.2.10 changelog. The CVE number isn't mentioned in the commit message, but you can verify that this is the fix by cross-referencing the CVE announcement.
https://cdn.kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.2.1...
https://git.kernel.org/pub/scm/linux/security/vulns.git/plai...
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...
Its not just Canonical but yes when a few month ago the local root exploit appeared, it wasn't fixed for a few days either.
It’s been nearly two weeks, a bit more than “a few days”
He probably is referring to Copy Fail/Dirty Flag exploits.
Why use Debían when you can use Rocky or Alma?
Why use Rocky or Alma when you can use openSUSE?
This is the end of Ubuntu and Canonical.
In the current age of AI, open source means exploits can discovered directly through the code. The flip side is the patches can also be managed.
We are in that period between when software was good enough and when software is certified as secure by the writers.
The days of importing frameworks and libraries written by strangers is over. I would say the entire industry is not prepared at this moment for the unpatchable event where the only solution is to power off or disconnect.
Don't expect closed source to protect you. LLMs are very happy to analyse binaries and decompile functions you need. It's barely harder to deal with software you don't have the source for. I did both security and reveng work with LLMs and they don't slow down.
Good job on moving away from Ubuntu, in the end Debian has been there longer and it's more trustworthy.
A hot take - agents with root access dynamically updating your system have crossed over the threshold of being more secure than not using them.
I still haven't done this for my servers with SOC2 compliance (for obvious reasons), but I've moved over my personal project servers to this pattern. They all run ubuntu and this CVE was fixed within 1hr of my agent seeing chatter on twitter about it.
Still in the testing phase of this pattern, but while I initially thought it'd be a terrible idea[1], I'm coming around to it more and more with the amount of major CVEs hitting.
[1] https://news.ycombinator.com/item?id=50221604
Switch to vanilla Debian. What I did, no real issues that weren't easy to fix. Rock solid still.
if only other OSes had the same CUDA support as Ubuntu. Now I know how solidworks users feel..
All other Linux distros have the same gpu drivers.
And you can have an ubuntu userland setup and any package necessary to run cuda in mere seconds on any linux distro thanks to toolbox and distrobox.
Withholding security-critical open source contributions to collect subscriptions is really low.
Bye Ubuntu
That's not what's happening here though. The haven't provided any patches for pro subscribers either!
Article contains the string "hve" which should no doubt be "have"..
beyond the nft/iptables mitigations discussed codex plopped out a kernel livepatch for my ubuntu kernels in about twenty minutes. the functions are ftrace’able so no trampoline/splice shenanigans required.
Do most VPSs even use distro kernels rather than kernels from the VPS provider?
Debian is, in every way that I know, superior to Ubuntu.
I switched after the aforementioned patch set broke containers and destroyed my server instance a couple years ago. Apparently nobody bothered to check containers before releasing the kernel.Why are you lying so much?
>no snap nonsense where you can't turn off upgrades
You can disable AND uninstall snap entirely. You can also disable automatic update of the specific snaps you have installed.
>stays close to upstream LTS kernels
Same as Ubuntu, which uses 7.3 on its latest release as of today.
>does not carry around some ridiculous kernel patch set
Custom kernel patches for hardware compatibility is a very good thing, and why Ubuntu works on a lot of machines compared to other distros.
>no irritating adware on login
There is not a single ad on login, and even after. You are an ugly liar.
There is an attempt to up-sell you on Ubuntu Pro on install, and again if you install the desktop separately.
All true as of when I quit Ubuntu a couple years ago. Your interpersonal skills need work.
[flagged]
How about WTF linux?
The TCP/IP stack has one of the most stable requirements bases of any component -- modern PCs can communicate with decades-old software and hardware, and the composition of layers design means the code can be easily tested, and is a great candidate for analysis via formal methods. And once you have a formally verified implementation, the stable requirements means you can make it safe and then leave it alone.
Pretty much every OS I can think of has had one of these vulnerabilities. Microsoft had a bad one not so long ago that affected IPv6 packets, not even at TCP level. Dedicated RTOS packages that run Mars rovers have had network-level code execution exploits.
Network routing is complex enough from a management point of view, doing it fast and safely is very hard. Formal verification sounds nice, but the network stack is more than a dumb pipe.
For bugs like this, I hope the addition of Rust to the kernel will lessen the UAF vectors, but I'm sure it'll be years before that happens. The binder folks did a safe rewrite and encountered downstream companies hooking kernel tracepoints for state determination, I can't even begin to guess what they'll do to the network stack and how that'll affect adoption.
Normal Ubuntu approach. Not news. I have personally got a bunch on 10+ year old bug tickets on Launchpad and only lately got a feedback like: "is this still relevant"?
Of course, if one hides a bug long enough it will eventually disappear or become irrelevant.
Yes, indeed, WTF Ubuntu?
We were using ZFS in prod a few years ago, and there was a one-line patch to fix data loss issues.
It took Ubuntu something like 6 months to “backport” it. I’m not at all surprised they are taking forever to patch a severity 11 wormable exploit.
Mildly disappointed, but not surprised. Anyway, the ZFS thing (and, before that, widespread systemd-related breakage of an old LTS) are why I don’t trust them in prod anymore.
I mean....insert Linux distro of any kind. Yes, hardware support is good, but most distros are otherwise pretty awful in many other regards now.
To pre-empt any replies: yes, I absolutely prefer BSDs over Linux any day. But even those are flawed and I really think we missed the Symbolics golden era. THAT would be the age of "own and live in the system". OpenBSD gets closest there. At least the codebase is hackable enough.
Linux went off the fucking rails. What the fuck is that over engineered yes command?!
Edit: https://github.com/coreutils/coreutils/blob/master/src/yes.c
270 loc for a tool that prints "y" in a loop. WTF?!
Meanwhile this exists: https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c
The rationale is explained in this 2015 commit: https://github.com/coreutils/coreutils/commit/35217221c211f3...
The current implementation is much faster than in that commit on GNU/Linux, as documented in this 2026 commit: https://github.com/coreutils/coreutils/commit/2b1c059e6a06ee...
The OpenBSD implementation is much slower than both the GNU versions from 2015 and 2026. However, their goals are different from ours, and that statement should not be interpreted as criticism of theirs.
The 99% use case is for just `yes` though. That is optimized for such a niche corner-case...
What downsides does it have for end users?
It makes the code way less auditable and more prone to bugs and errors. Or let the kernel change its paging mechanism and now your fucking “yes” tool needs an update to be “efficient”. The tool has one job…print yes or another word you give it. It by definition does not have to optimized to oblivion. Same goes for echo.
It’s arsinine to optimize it to that level instead of just keeping it readable and maintainable. And portable.
The gnu version is 100% not easily portable because it has assumptions about the underlying kernel.
The current implementation works on any system with read and write system calls.
The Linux optimization just uses splice and vmsplice. If those APIs are changed to avoid zero-copy, as was considered for some time after the AF_ALG security issues, it is unlikely that another API would take their place. So, no, I do not think it needs any changes if Linux changes.
> It by definition does not have to optimized to oblivion. Same goes for echo.
I don't know about oblivion, and non-portable optimizations are not good. But perhaps yes(1) and echo(1) are among the tightest inner loops of scripting. You would not want them to bottleneck the pipeline. You'd want them pumping output faster than it could be accepted or written out.
Perhaps there is an opportunity for a /dev/yes, which acts like /dev/zero, only it continually outputs whatever filename it was opened as (good luck!)
I think NetBSD and OpenBSD do just fine with the simple version. Or maybe they write better scripts :)
What can go wrong with allocating memory based on user input….I wonder….
> Anthropic says it built a working exploit that gets root on a server. A total takeover.
No offense but Anthropic says that every time.
maybe once it comes out you will need to pay them to get the patch xD
I suppose this kind of stuff is why you will find some places who roll Debian in prod but almost never find Ubuntu?
on laptops etc. its less impwct because (i think) most people are sensible enough not to have all kinds of listeners open all the time?/(right guys??? ...RIGHT GUYS???)
dont forget it can also be used as LPE if its a local host listener. and LLMs can bake u a nice exploit for it too.
Go Debian or perhaps consider freeBSD or OpenBSD if your workloads permit. they are more feasible, and sensible by the day, not just trying to poop on Linux, its simply much more targeted for now, and because it moves faster, and thus is bigger, it will have more holes.
a lot of ball dropping all around lately in lots of incidents and CVE. stay safe out there!
I have the same general feelings, but then I recall my years as an OSS developer and being abused by people who contributed absolutely nothing to my projects. Not money, not code, not documentation, not even grammar corrections. I'm sure anyone who's been involved with reasonably popular OSS can relate.
I am not contributing to Ubuntu in any way, and that puts it into perspective.
(I still directly contribute to OSS and release OSS projects, but absolutely refuse to engage with the least bit of hostility. Any of that is an insta-block.)
Edit: Whoah the downvotes and comments. I'm not saying that Ubuntu is doing well here. I'm trying to point out that a a vast percentage of the complainers are not paying customers, and maybe if they did pay, Ubuntu would have more incentive and resources to work more quickly.
People are paying money for Ubuntu, though. I suppose if only the free versions were unpatched we could consider the ethics and merits of who is allowed to complain about what, but when the paying customers are also being left out in the cold I don't think your argument has much merit.
Sure, and those people have a right to complain.
But, imagine if the complaint vs paid ratio were more equal.
Right now, the ratio is massively skewed towards complainers vs paid. (>99.9% I'd guess)
I guess yes on internet, enterprise customers just call their account managers rather than write a blog.
Ubuntu is a for profit product by a commercial company, Canonical.
Most of it's user base are non-paying "free tier" customers.
Their product is their product. It's not as if they should deprive their paying customers of a fix to spite the non-paying.
How is that relevant?
I have fond memories of burning Ubuntu to a CD being my first introduction to Linux. I chose to preserve those cherished memories rather than sully them through actually using Ubuntu.
I'll add that they were a day or two late to patch the brotli issue, other than Ubuntu Pro LTS, which was still "under consideration" or whatever they called it, for another few days to a week. https://ubuntu.com/security/CVE-2026-111497 Now it says it's fixed, but on my old server I'm still not getting the updates for whatever reason (maybe I have it set up wrong? I dunno.).
I hate to be the guy to complain about a free service (Ubuntu Pro is a source of revenue, but it's free for individuals) but if I knew this was actually was actually being offered I would (hopefully!) have switched off by now.
They were also really slow on heartbleed
You can build a kernel yourself, you know?
Having migrated out of Ubuntu since 2016 (when they made systemd mandatory), I can only marvel at my own prescience... ;-)
Inflicting some pain to sell Ubuntu Pro maybe?
Ultimately, Ubuntu was never more than just a respin of Debian with brown wallpaper and shovelware added. It's time to let it go.
Plus snap & Amazon
They are rewriting those bugs in Rust.
Ubuntu has always been worse-Debian, I've always said it, now I have the strongest evidence in my favor.
The fact that Ubuntu (still) hasn't patched this (despite the fact that I'm pretty sure Opus 5.5 could figure it out in a few minutes) is pathetic. And it's very annoying for me because I have two servers that I need to consider migrating off of it now because Ubuntu clearly doesn't care all that much about security vulnerabilities like this. Get your shit together, Canonical. We all know you can do way, way better than this.
Where is the bug-List??
> Anthropic says it built a working exploit that gets root on a server. A total takeover.
Can we stop giving value to what is said? It's time to only accept PoC's or at least some documentation as proof.
The recent PHP vulnerability made this even more apparent. LLM's were panicking, but the server were fine...
Everyone is just using Ubuntu for free of charge for the most part. You get what you pay for.
On another note, you can probably easily install the Debian kernel onto your machine.
"But we need signed kernels!" Well, that's a big "I told you so" from the people that were against only a handful of distros being able to create signed kernels with MS derived keys like 15 years ago.
You get what you pay for? Honestly this is so very disrespectful of the work thousands of people have and continue to put into Free Software including all Linux distros (Ubuntu too) as well as other operating systems and software. Really really disrespectful.
Having to get the client into call just so they go and click authorisation for adding some signing keys on VMs (as it was in pre-boot stage) just to add some driver wasn't fun
What an awful system
> Everyone is just using Ubuntu for free of charge for the most part. You get what you pay for.
That ignores those paying for Ubuntu Pro. They are not getting what they paid for.
kindda interested in how many routers are vulnerable
Ubuntu seems like it hasn’t been in very good hands for quite a while now
Reminder that Ubuntu used to bundle spyware - I dropped it at that point and never looked back, trust broken.
https://www.fsf.org/blogs/rms/ubuntu-spyware-what-to-do
First time?
agreed what the fuck are they doing, i moved off all my homelab and pc's to debian/fedora a while back.
ontop of the bullshit ads you get the terminal for paying for theire premium bullshit
> and I considered it the solid, no-drama LTS distro. Fuck that now.
There's been lots of drama on Ubuntu which OP either completely missed or ignored. Ubuntu has been getting worse for over a decade now.
Yes, this is a fuckup by Canonical
But it doesn't sound too hard to backport a patch from Debian to Ubuntu yourself.
So if it's a critical security concern to your company, open your laptop and get to work.
I mean.. how many people are using multipath on Ubuntu? This is a big issue for datacenter systems that are using fancy networking features that Ubuntu users probably aren't.
Go programs listening on TCP have multipath enabled.
So they do. Also they mention in the golang-announce bulletin that MPTCP might not even be required for exploitation, it's just that the PoC requires MPTCP.
The patch itself isn't related to MPTCP, but the bug is hard to exploit. AFAIK, Anthropic is the only ones who claimed exploitation using their unlimited frontier models without safety restrictions. So non-MPTCP configurations may also be vulnerable, but exploiting them could require even more resources. I've tried to trigger KASAN using Qwen 3.8 27B @ local RTX3090 - no success after 96 hours.
i would then give claude/codex full access, and ask it to do a temp patch, if they allow lol.
it is, indeed, insane
Honestly, I agree. I need to provision a new VPS for a personal site and I’m holding off until it’s resolved.
Not to mention however many production services teams I work with build and maintain that run on Ubuntu.
Ubuntu are dragging their feet and it’s not good enough. Nowhere near good enough.
Get it patched NOW!
And if you’re on here and you work for Ubuntu, then what the hell are you doing reading this when you should be shipping a patch?
Seriously: get on it, will you?
I've all but stopped using traditional "Linux distributions" honestly.
[dead]
[dead]
[dead]
[flagged]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
[flagged]
Where is he moving his shit to, then?
Probably Debian.
> I'm moving all my servers off Ubuntu. Well justified.
you mean to say you didnt review the codebase before putting it in production? you get what you pay for
They're too busy replacing something else with a Rust rewrite.
Did Omarchy patch it? Anyone knows? (Not that I'm using it now, but I'm interested.)
Arch patched the vulnerability, yes. Dotfiles don't change that.
<animation of DHH in a race car driving bits and bytes to Linux machines>
What difference does it make? Version N (TEH LATEST) is considered secure until it isn't and the same show repeats with version N+1 but we already know it's also compromised.
The obvious difference is that version N-1 has a known vulnerability that could potentially be exploited, and everyone now knows about it.
And the version N+1 has exploits only the hackers know so as long as the general public is oblivious it's "secure".
Let's be clear the security vulns will never end and if you're running anything connected to the network eventually you'll get pwned.
Where is my cup to collect all these tears from people upset about free software not getting fixed fast enough?
I wonder what is slower, these people pulling out a credit to pay something or ubuntu fixing their issue?
Probably right next to your reading glasses, my dude.
Maybe grab those first, though.
They are on my face. It's how I read a blog post and comments of people who are complaining that free software isn't being updated fast enough for them.
WTF Ubuntu! I'm not paying you for updates... so where the fuck are my updates bro?!
Canonical literally has paid security support. So people DO pay for updates they are not providing. Stop licking them boots
"The free operating system that I use is not giving me enterprise level security updates"
I believe you can contribute to Ubuntu's source code right? Why don't you fix the issue then?
This doesn't work in practice. That's not really how OSS works; it's a naive interpretation. I can go into details if you'd like, but first: Have you taken this approach before? What were the results? I find it usually ends up in discussions/arguments with the owners, and it doesn't get merged. And I see the other side too; reviewing PRs is a burden, and the submitters often will fix their own problem, while introducing complexity or problems elsewhere. Also, it's generally MUCH easier for a maintainer/owner to update software than a rando who wants a bug fixed.
I fix it for myself, share it upstream, and have no fucks to give if the gatekeepers review it, reject it, merge it, or belch any purity bullshit in between.
The beauty of OSS is that you don't need permission from anyone to modify the code to your own needs.
Then you build the iso yourself and distribute to every cloud platform? It’s not always that simple.
Wouldn't it literally be as simple as hosting a ppa archive with your custom kennel on it and adding that ppa to all target systems?
The glory of OSS is that "you can, if you must" is the answer to every possible what if you can encounter or imagine.
> "The free operating system that I use is not giving me enterprise level security updates"
Canonical absolutely is marketing enterprise security updates (at least for those who pay). I don't see this in the paid ESM updates channel yet either?
Their main point is that Canonical do in fact charge for security updates (they charge some companies for support), and yet are not providing them.
From the article:
> Oh and btw, distros run by volunteers (Debian, Arch, Alpine...) hve shipped the fix. Meanwhile Ubuntu, made by a company that sells security subscriptions, hasn't. This is true as of 2026-11-02 14:48 UTC.
Ubuntu is one of the larger companies in the OS space and advertises themselves as providing long term support with rapid security fixes. AFAIK they haven't released a fix for their paying customers either. If they were complaning about arch or debian then I think you would have a strong point, when those distros have fast fixes but ubuntu doesn't I'm not so sure they that criticism of ubuntu is unwarranted.
(Also, ubuntu already has the fix. What they're dragging their feet on is releasing the updated version. I don't think anyone outside ubuntu can help with that process)
Getting commit rights for kernel to "just fix the issue" in a corporate led dev project.
Let's see you do it.
Probably depends on the company. Plenty love to publish useless blog posts about how “We, a SaaS company that produces React components, fixed a vulnerability in Ubuntu Kernel” because we’re involved in all of our tech stack like that. Linux kernel, node and react is our stack and we take ownership of it seriously dawg.
Two weeks late is hardly “enterprise level”
If they don’t have the resources to handle this, they should be recruiting more help from their community
> The free operating system
Ubuntu Pro is $500 per machine for enterprise.
https://www.gnu.org/philosophy/free-sw.html.en
Do you understand what an enterprise software support contract is?
Yes, and it's only natural to pay money for it. The software is still free (speech) and incidentally also free (beer).
Which OP doesn't pay, as they claim they use Ubuntu because it comes as default with VPS
I don’t think the paying customers are getting the patch either.
No updates for paying users of Ubuntu Pro either
The code that fixes the issue has already been published: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Just not picked up by this distribution which advertises itself as having “Enterprise-grade support and integration”. https://ubuntu.com/desktop#:~:text=Enterprise%2Dgrade%20supp...
But this is C, they're busy porting the patch to Rust...
The most famous not-free-as-in-beer OS that specifically marks enterprise as their target market actually only fixed this yesterday... whatever you may want to take from that.
Ubuntu is not a small open source project ran by maintainers, Canonical is a full fledged b2b company with 600+ employees.
Canonical ltd is a multinational tech company with hundreds of millions of dollars in revenue from enterprise contracts
I suspect at this point that it’s a bunch of techno-bureaucrats at Canonical who are dogmatically sticking with their release cadence because artificial justifications. I have worked in big organizations where The Process, or The $place Way of Doing Things, has become so big that the bureaucracy takes on a life of its own and you end up having a whole team of people who just manage the process so that the people actually doing the work can maybe get something done.
I haven’t used Ubuntu for a few years now but I’m glad they’re getting this trial by fire now. This new era of software vulnerabilities is going to reduce the viability of a lot of smaller distros who more or less are entirely dependent on upstream for security and reliability. I sincerely wish the Ubuntu folks well but this is a sink or swim moment, and even if they sink it will be a net positive for Linux as a whole as weaker projects get picked off like the slowest antelope in the herd.
Meanwhile, Debian lol
"If you're not paying, you're the product-" hey jerks, the analogy doesn't always work
Not sure I understand what you're referring to.
Debian has a patch out, do they not?
Sorry. I just meant, Debian's free as in beer. Ubuntu can be too but I thought there was more of a visible avenue to pay for it. And I just get annoyed with the 'you are the product' as a slogan because you get used plenty, exploitatively, even if you do pay for something. And many ethical things are in fact free
The fact Debian apparently does things properly just hammers it home
It was a lazy reply and I apologize
Calm down, man. I think Ubuntu is doing o.k. here. What is pretty bad that people cannot read advisories anymore and fix there machines, instead crying for their mama (in this case Ubuntu).
Use this firewall rule and you are fine - it blocks the tcp options negoation - and things remain working of course: ` nft add table ip cve_2026_98432 nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }' nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop `