I’m surprised that no one seems to be discussing this at all. Has there been any news or discussion about it?
May I ask if there is any temporary fix or mitigation available for this issue?
In our experience, it usually takes around 1–2 weeks for fixes to become available in Rocky Linux after Red Hat releases them. For a production environment, it is quite difficult to remain exposed to this risk for that long.
Also, is the Rocky Security Repo that was mentioned previously still useful? Can it still be used to obtain security updates more quickly?
The Red Hat link I gave clearly shows a mitigation…
Generally critical fixes that have occurred recently have been fixed and placed in the security repo when Red Hat were taking too long to do it. Usually in those circumstances the fixes were done within a few days. It’s clearly stated on the Rocky website 24-48 hours best endeavours but could take longer. If your system is mission critical, then perhaps you should be looking at paying for a RHEL subscription?
Thanks for the clarification.
I understand Rocky Linux updates are best-effort and not an SLA.
We will apply the nested virtualization mitigation for now.
Thanks.
The long and short of it is that if you want to use a RHEL-based distribution and you really care about security, then RockyLinux is a poor choice. You are much better off with either AlmaLinux or Oracle Linux, both of which have a significantly shorter patch release delay aka the time between Red Hat releasing a patch and the rebuilt distribution releasing the patch. Alma Linux is faster than Oracle at releasing the initial release of a new major version. I put that down to Oracle offering up a new UEK, which involves more engineering effort. Once released, they are on par with, if not slightly better than, Alma. This has always been the case for the entire history of the Rocky Linux project.
For example, 5.14.0-687.24.1 was released by Red Hat on the 9th, by Alma on the 10th, and, as far as I can ascertain, there is, as of this post late on the 11th, no release from Rocky. In fact, Rocky has not yet released 5.14.0-687.23.1, which Red Hat released on the 8th of July to address the Bad Epoll flaw among other fixes.
Unless you have some pressing requirement that dictates the use of Rocky, then it is unfortunately a poor, if not unprofessional, choice given the current cybersecurity threat environment.
It does unfortunately seem like the recent cadence of security releases has overwhelmed the Rocky maintainers - and, to be fair, it has been extremely high. As far as I can tell, the last kernel released for Rocky 9 was 5.14.0-687.17.1 on June 24th. Since then, RHEL has released:
- kernel-5.14.0-687.19.1 on June 29th
- kernel-5.14.0-687.20.1, also on June 29th
- kernel-5.14.0-687.22.1 on July 6th
- kernel-5.14.0-687.23.1 on July 8th
- kernel-5.14.0-687.24.1 on July 9th
… all of which are “important” severity. So we’ve gone from what used to be roughly one upstream kernel release every couple of weeks, to nearly one every two days.
There might not even be a point in finalizing the release of a kernel that fixes a LPE if another kernel that fixes a different LPE is released the next day, so I guess it’s both fair and reasonable that they skip some kernel releases for a bit. But while it is a free service and no one should have excessive expectations, it would be nice if there were some official word on the state of things.
I’ve just posted this on our channels, because updates should be released far quicker and they aren’t.
Kernels are in staging. Hoping that they push into prod and out to mirrors soon.
The RelEng team just completed a large migration to a new data center (including the shipping of physical keys from one to the other). Add to it the SecureBoot key issues and they’ve been very busy.
If security is so important you can either:-
- Help out. The teams would love to have more people who can do this so that it’s not just a few volunteers who have a life outside of Rocky.
- Buy CIQ Rocky which has all of these patches out at lightning speeds.
Or accept that Rocky is no longer fit for purpose in the cyber security threat environment that we face in 2026 and pick a different RHEL rebuild distribution that has a multi year track record of a significantly lower patch release delay.
It’s tough message for sure and certainly unwelcome by the Rocky maintainers but it is the harsh reality we face. I will be having a conversation with my boss as soon as he gets back from holiday to reevaluate our choice of Rocky Linux because right now it is unsustainable.
These are being pushed to prod this morning, expect mirrors to sync by mid-day PST (will update when finalized).
For this particular issue, just a couple of notes on the reason for the delay:
- RH released the Januscape updates for 9 and 10 on Wednesday evening
- We had them imported on Thursday, but due to issues with the SB environment (brand new we just finished standing up, but this won’t be an issue moving forward), they weren’t built until Friday. That’s also when we had our own fixes for 8. RH still hasn’t fixed 8
- They weren’t pushed to production immediately after the build primarily due to the time it takes to do a compose, a longstanding issue that impacts our time to release. This is what we’ll be working on next.
Friday would have been our target release date for these fixes.
We’re keenly aware that our release cadence isn’t what we’d like it to be. We hear you.
Now that we’ve created some space for ourselves and finished other necessary work, we’ve cleared the path to be able to begin work on our #1 priority, which is improving our compose process and introducing automation to improve our release speed. We’ve been aware of this and have been tracking it at a high level on our project board.
Expect updates on this by EOW.
Till next time you stand up a new SB environment, and leave a 12-day window (since 5.14.0-687.19.1 on June 29th) in which you are unable to issue packages.
As I said previously, both AlmaLinux and Oracle Linux have a five-year history of a significantly shorter patch release delay than Rocky. We moved from Alma when on 8 to Rocky for 9 due to vendor support for Ansys. Without dramatic and quick improvement, I will be switching back and forgoing the vendor support on Ansys (which turns out not to be that useful; they are only supporting 9.6 at the moment) in favour of not locking 100+ people out of our HPC for days longer than necessary.
Were these issues just related to moving internal Rocky infra? No secure boot issues in Rocky itself?
Yes, there are no secure boot issues with Rocky itself. The only issues were with the configuration of the new environment.
@jabuzzard, are you happy to help out with the improvement? Over the last few months there have been major changes to release engineering and we’re now working on plans to automate a good chunk of the process. What we have now isn’t good enough. Will you help us make it better?
Hi all,
Does Rocky Linux provide release notes or security update information similar to the AlmaLinux blog?
For example:
I would also like to know whether there is a page where I can check the status of each CVE, such as whether it is under review, being addressed, or has already been fixed.
Does Rocky Linux already provide this information somewhere? I may have overlooked it.
Thank you.
No secure boot issues in Rocky itself?
Sorry. I wasn’t as clear as I probably should have been. Correct. Nothing with Secure Boot itself. The keys were “expiring” and there was a ton of work and effort to get the shims signed with the latest keys. I know it took an extraordinary amount of effort to get all of that done and tested.
I believe you are looking for this:-
And as of today, the latest kernels are now available. They are still propagating to the mirrors but they are out. 
Big props to RelEng!
Noting that if LPE’s are your problem, then GhostLock (CVE-2026-43499) has hit. No mitigation; root using the public exploit with 97% reliability in 5s and affects everything from RHEL6 through RHEL10, so basically everything. No patches yet from Red Hat. Debian Trixie and Ubuntu 26.04 do have updates, but not a lot else.