See previous discussion and the actual talk on YouTube:
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...
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.
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.
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.
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.
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).
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.
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.
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 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.
This isn't relevant to the CVE, but counters the claim that Debian is always a suitable choice of distribution.
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.
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.
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 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.
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.
And also plain Debian repositories gaining popularity over PPAs. WeeChat and Synapse (Matrix) both offer one for example.
Christ that was 2008.18 years ago. My Linux 'experiment' is old enough to vote
[edit] omg circa 2006, firefox was still new back then
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.
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.
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?)
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.
[1] https://docs.oracle.com/en-us/iaas/Content/Compute/Reference...
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.
(But 100% agree this shouldn't be necessary).
To be clear, Ubuntu Pro doesn't have the fix yet either.
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.
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.
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 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.
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.
At one point that was less than $100 of RAM which isn't a big deal for the trade.
I should have asked what is it there in replacing yourself with a mishmash of external world.
To be clear, Ubuntu Pro doesn't have the fix yet either, in case anyone's confused.
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".