upvote
If you read commit logs of, say kernel.org and a distro kernel, and aren't concerned you are blissfully ignorant (and it is worse for the broader userland repos). It's particularly bad when they don't track a kernel.org LTS. Their kernel orgs are pretty lean and this has been the status quo for decades. CVEs of sufficient stature like this will get fixed but majority of other issues slip by unnoticed. LTS is kind of a myth, it trades ABI and API stability for a lot of other issues.
reply
"Their kernel orgs are pretty lean"

For years, Red Hat employed more kernel developers than anyone and contributed more. These days they're "only" the fourth largest contributor, after Intel, Google, and Meta, but they are still among the largest corporate contributors.

If that's a lean kernel org, I don't know what a fat one would look like.

reply
My hearsay, from friends and colleagues that work(ed) there, is that the shipped product is not really where you see these "heavy hitters".. a lot of the maintenance happens offshore.
reply
Just makes sense that they would put the "heavy hitters" on feature development, not backporting security patches.
reply
Unfortunately, as a ZFS on Linux user, LTS is the best way to get continual updates without breaking my system.
reply
Probably best to not leave any ZFS system connected to the internet then.
reply
Or perhaps this illustrates the value of running all web services under KVM rather than bare metal.
reply
Over the past few months I've started to install newer ubuntu kernels using the mainline PPA. However, it goes long periods of time without getting updates, so it's not really a satisfactory solution. In one case I just built the kernel myself.

LTS doesn't work if you want immediate fixes like the current environment requires.

reply
Given the current and rapidly upcoming environment, would that not imply that those are no longer viable choices? As like a fairly urgent emergency consideration?

If they cannot demonstate being systematically able to adapt towards the required reaction time (minutes? hours?) by almost-comically many orders of magnitude (multiple weeks), and it is only going to get worse, then what other conclusion could there be?

Like they'll only organizationally adapt when it's far too late (everybody using their shit has already been pwned), and then it'll be an unpracticed emergency adaptation.

reply
No, they are providing a service, LTS, that customers still want and pay for. Only once the customers realise its not a workable product and they want a rolling update product, with all the changes that implies, will this change.
reply
> How are Ubuntu and RHEL not fixed?

Ubuntu has had kernels in the "proposed" component for several days now if you want to pull it in manually. Not yet pushed to "security" or "updates".

reply
Is there an RTFM for 'pull it manually'?
reply
enable the proposed repo (and pin it to a lower priority) and install the package explicitly

https://ubuntu.com/project/docs/SRU/reference/sru-verificati...

or download the individual package (and dpkg --install ... but this doesn't check signatures)

https://ubuntu.pkgs.org/26.04/ubuntu-proposed-main-amd64/lin...

check https://ubuntu.com/security/CVE-2026-98432

reply
I’m pretty confused because apparently Anthropic is the group that followed “responsible disclosure” but apparently even though upstream was patched a couple weeks ago, still nothing on either.
reply
It seems particularly crazy for Ubuntu given that Debian released their fix something like a couple weeks ago.
reply
deleted
reply
They pull from Debian unstable every 6 months and that's it. Afterward, changes made in Debian mean nothing to Ubuntu.

Don't trust Ubuntu's LTS promises, either. Most of the modern packages you care about are in universe, which almost never gets patched after the initial release.

I think they deliberately leave the free LTS version insecure in order to sell Pro licenses. But guess what, even Pro doesn't get timely patches.

reply
It's one of two things: Either they have found some regression with enterprise customers, or they are not happy with the fix.

RHEL runs with MP-TCP disabled by default, they initially listed it as Important only to later raise it to Critical.

reply
I don't think I can recall an instance where there was an issue this bad (a box being vulnerable just by virtue of being connected to the internet, or exposing nothing other than ssh) and I didn't have timely patches for it. I had to turn off my server and home automation system because of this. Really not acceptable at all and makes me want to switch everything to debian.
reply
Going by the proxmox forum the fix is already in the sources (proxmox released their kernel based on them a few days ago). But I could not see, if it is already released for the users.

https://forum.proxmox.com/threads/cve-2026-98432-in-proxmox-...

reply
Yes, we (Proxmox) included the fix for this in 7.0.14-25, which was initially packaged two weeks ago.

It went through internal QA and to the test soon after that, then a few days later to the no-subscription repository and as of yesterday morning CET it was cleared for the enterprise one, so it's available on all repos of all Products we got in their current supported releases.

For kernel updates we where even more conservative in the past, but with the current churn on often quite relevant fixes picked up the pace a bit on moving them along, trying still to balance rolling out fixes fast(er) while not doing that so fast that tricky (hardware/setup specific) regressions don't get caught.

edit: As this makes the rounds we also released a PSA for it now [0] to make our status here easier to find.

[0]: https://forum.proxmox.com/threads/proxmox-virtual-environmen...

reply
>How are Ubuntu and RHEL not fixed?

IMNSHO this makes them unfit for purpose. I think this is the nail in the coffin for Ubuntu for me.

reply
It's not a good look.

I pulled in from -proposed this time.

Ubuntu was slow on the brotli / CVE-2026-111497 updates as well.

reply
What would you suggest for enterprise use of Linux if RHEL is no longer fit for purpose?
reply
I'd be seriously considering Debian or, hear me out, NixOS. We run all our work servers on Ubuntu, but ~6 months ago I switched my workstation to NixOS and I couldn't be happier. I've been following "latest" or whatever they call it, being able to treat the OS package versions like the rest of our software (update the flake.lock file and then burn it in in dev+stg for ~2 weeks before rolling to prod) is pretty attractive.
reply
> NixOS

No legit enterprise is running that clownware — ever.

reply
I certainly know people who run NixOS in commercial production. It's hardly "clownware".
reply
It used to be true that no one got fired for buying IBM. Now, I would laugh at any organization that chooses IBM.

Times can change.

reply
I think helsing and or andruil do?
reply
Running regression tests I assume; they can't just YOLO shit like most OSS projects for the exact reason you mention.
reply
It could be that it is more YOLO not patching this ASAP. Maybe better to risk some regressions.
reply
For a month?
reply
deleted
reply