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

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.

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.

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?

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.

They're totally asleep at the wheel, it's malpractice. The pitch for RHEL is highly competent maintenance you can't get elsewhere

I believe RHEL/Alma/Rocky has released patches today. I have a notice about they have done so.

Is RHEL really unpatched still? Looks like patches came yesterday: https://access.redhat.com/security/cve/cve-2026-98432

I use NixOS btw

> 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?

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.

> 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.

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.

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.

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.

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.

> at least be constructive about it

I think the proposed solution here is pretty clear. Patch the bug.

Very helpful information, thanks!

But Ubuntu is not the embodiment of "open source". It's a business. With managers...

"Speak to the Manager" is absolutely the best way to summarize this. I pay nothing for your product, but don't you know who I am? I'm moving all my VPS work loads away from you!!!11!

> 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

>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"

If you had to manage what has become critical infrastructure around the globe using something like Launchpad, you'd understand.

It's not optional.

I think the official CTF is up here:

https://ubuntu.com/security

server: nginx/1.14.0 (Ubuntu)

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).

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.

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 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 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.

> 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?

  sudo dnf --enablerepo=security update

  kernel-6.12.0-211.69.1.el10_2.x86_64

14.04 LTS trusty is not vulnerable fyi.

This is what I want more information on, especially before we start pitchforking ubuntu or whoever

I think they shipped patches yesterday. Which is still a long wait.

https://access.redhat.com/security/cve/cve-2026-98432

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

Because that doesn't allow for sensationalizing the frustration.

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.

Talking of which, is there a link to the temporary fix?

[dead]