This is a problem for anyone running publicly accessible web applications (or other kinds of applications) because any attacker who has previously gained shell access through bugs in some code without exposing their presence can now elevate to root.
According to Debian Security Tracker, trixie and bookworm have been patched (bookworm on 3 July). The vulnerability was publicly announced on 7 July. AlmaLinux 10, 9 and 8 were patched on 9 July. RHEL 10 - only a few hours ago (13 July). RHEL 9 and 8 haven’t been patched yet. As I’ve already said on the Mattermost chat I can’t seriously consider RHEL, much less Rocky Linux, for any server instance that I will set up in the future.
If you check RHEL, the same is also true. Patches for RHEL 10 and RHEL 9 were released on July 8. Patches for RHEL 8 are not available. Red Hat cve-details . Rocky 10 and Rocky 9 patches were released a few days later on July 11 and July 12. Rocky 8 will not get patches until a few days after RHEL 8.
My problem is I have a six-figure storage system for our HPC that mandates the use of a RHEL-based distribution. I tried mixing in Ubuntu for complex reasons around broken DFS support in the kernel CIFS driver from some time shortly after 3.10 and not fixed till 6.8 last year, and it didn’t work, and I was told in no uncertain terms not to mix distributions in GPFS.
While I agree LPEs are not great, as they can be chained with other vulnerabilities, in HPC we are particularly exposed because, by the very nature of what we are doing, users have shell access by design, so there is no need to chain in another vulnerability.
In your case AlmaLinux would probably be a good choice, its developers seem to care a lot about this group of users, which also includes shared hosting providers. You’ve also mentioned Oracle Linux, but I don’t know if it has ever released security updates ahead of RHEL like AlmaLinux has done?
My very first server was running Debian Etch, it was about 20 years ago, but later I got to like CentOS more, at least on servers. Now I’m seriously considering a return to Debian.
Oracle Linux has two kernel options: your standard Red Hat compatible kernel (RHCK) and an alternative Unbreakable Enterprise Kernel (UEK). This is completely different to the RHCK kernel; it’s 5.15-based rather than 5.14, on 9, and consequently Oracle patches it on a completely different time scale, independently of Red Hat, and frequently faster than Red Hat. Note that if you do a fresh install on Oracle Linux 9.6+, you will get a 6.12 based UEK instead, but the older 5.15 is still getting updates.
To be totally honest, if you need/want a RHEL-based distro and the RHEL kernel is lacking drivers you need, then Oracle Linux with the UEK is a really good choice because the UEK carries a LOT more drivers than even the extended AlmaLinux kernel or, for that matter, bodging things with Elrepo.
The only issue with both Oracle Linux UEK and the extended AlmaLinux kernel is when it comes to needing kernel level compatibility and especially source code kernel compatibility. One of the reasons we switched from Alma to Rocky is that we had some issues building the GPFS kernel module on one of the “extended” AlmaLinux kernels. They did say they would regard that as a bug and fix it, but we decided to go with Rocky instead and sidestep that issue when upgrading from an RHEL8 base to an RHEL9 base. That, along with the Ansys support, was the deciding factor. That decision is now under reevaluation.
Personally, at home I use Oracle Linux because it has drivers for all the TV tuners for my Plex server that Red Hat ripped out in 9, along with a lot of image capture cards (without notification initially in the release notes) and seem to have added back in, in 10.2 (AI vision workloads, I imagine and entirely predictable when they ripped it all out).
Based on what you’ve said I think you should also consider paid CIQ support for Rocky Linux if your company budget allows it. The professional approach to fixing security bugs seems to be limited to CIQ and aimed at paying customers. What the rest of us get for free in Rocky Linux can only be described as subpar. (In my case I’m not getting paid for my effort or earning any money from it so of course I’m not going to pay for support.)
RHEL has lost a lot of reputation by not providing important security updates on time, so I wouldn’t even use the free developer subscription, let alone a paid subscription. And it’s not okay that servers which are run not-for-profit can be vulnerable to exploits for a long time because they don’t pay for support. Such an attitude harms the Internet as a whole. Maintaining a Linux distribution is hard and if maintainers don’t have the manpower to provide security updates quickly then the purpose of such a distribution is questionable.
Incidentally, I noticed 5.14.0-687.25.1 with the rtmutex LPE (“GhostLock”) fix was released by RHEL on 2026-07-13 and by Rocky less than a day later, so hopefully that means all the problems have been worked out. Keep up the good work.
Sure, let’s celebrate that Rocky Linux released an update about 30 hours after Red Hat, without caring that Red Hat released its updates 6-7 days after the vulnerability became known to the whole world, with exploit code and no mitigation available. A problem with RHEL updates was already noticed in May when the Rocky Security repo was created, but at the most important time of trial so far, this repo remained unused.
