Due to the current reports on the CVE-2025-38352 security vulnerability, here is a question for the forum:
Does anyone have any current information on Rocky Linux 8.10, specifically kernel 4.18.0-553.72.1.el8, regarding the above issue?
I cannot find any information on whether this security vulnerability has been fixed in the current kernel (updated today).
Please refrain from suggesting that I upgrade to Rocky 9.
Regards
The first place to check is what Red Hat says (about RHEL). For that CVE that is: cve-details
All RHEL (except 6) are Affected. That is not fixed yet. Rocky 8 shares the issue with RHEL 8.
Red Hat has no mitigation to offer, and notes that there are known exploits. They must be busy with making a fix.
In this case that would not help either, as el9 is just as affected as el8.
OK, I’m busy waiting.
Regarding Rocky 9: We also use a machine with kernel 5.14.0-570.37.1.el9. On this machine, the kernel parameter CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y is effective.
If I understand correctly, this means that the problem does not occur.
Regards
RedHat has released a fix.
See here:
https://access.redhat.com/errata/RHSA-2025:15471
Waiting for Rocky…
Yes, and if you read Rocky website, normal updates appear in 24-48 hours after they are released upstream by RHEL.
Since they were released yesterday you need to reset your expectations and be more patient.
@iwalker
You wrote 1 to 2 days. It seems to me that the cycle is taking a little longer. But I remain patient.
Glad to hear that you remain patient. And I’ll quote the website here: Rocky Linux Release and Version Guide - Rocky Linux Wiki
People also have a life, they have their day jobs, families, real life problems, issues etc.
RHEL release updates quickly because they have hundreds or thousands of employees, and people pay for subscriptions to get those updates quickly. So if it takes longer with Rocky, remember that. Or perhaps if it’s taking too long for your requirements, maybe you should be paying for RHEL?
But anyway, I just did this on my system:
dnf update
Installing:
kernel x86_64 4.18.0-553.72.1.el8_10 baseos 11 M
kernel-core x86_64 4.18.0-553.72.1.el8_10 baseos 44 M
kernel-devel x86_64 4.18.0-553.72.1.el8_10 baseos 24 M
kernel-modules x86_64 4.18.0-553.72.1.el8_10 baseos 36 M
and mirrors seem to show that file:
kernel-4.18.0-553.72.1.el8_10.x86_64.rpm 11017296 2025-Sep-07 15:44:45Z
So was most likely accessible a week ago assuming mirrors synced around the same time, perhaps your systems are not configured properly to access the internet to download packages?
We could assume RHEL release an update let’s say September 7, we then have 24-48 hours best efforts to release that, which could say September 8 or 9. Then you got mirror sync times to get that synced all across the world (incidently we are not responsible for all mirrors), which can also add another day or two on top of our efforts. So then it could be September 10 or 11 at that point.
I think this CVE is only fixed by kernel 4.18.0-553.74.1, not yet by 4.18.0-553.72.1
Ah yeah true 
so little longer to wait then..
Is there a chance the new kernel is landing anytime soon? I saw it was already in staging and since AlmaLinux already has a release it shouldn’t be that hard, right?
Patience is a virtue. So many people complain that things are taking time, but don’t offer their assistance to help out to make things quicker. They expect everything, and yet do nothing themselves.
If you cannot wait, perhaps you should pay money for a RHEL subscription. But I guess you don’t wanna do that right? 
Afaik we’re donating generous to the Rocky Foundation, but I guess Alma is a wiser choice for our money.
On a more serious note, a CVE with a score 8.5 that has been in the wild for two months and gives local users root permission that hasn’t been resolved is a bit sour to say the least.
Well considering RHEL only released it on September 10, you cannot blame us for that - perhaps you should complain to RHEL that it took them 2 months to resolve it. It’s September 17 now, and as it’s appeared in staging (as you mentioned) it most likely will appear shortly.
Rocky is based on RHEL, so unless RHEL release the updates, then we don’t have them. Alma is only ABI compatible now which means they can diverge and put newer packages if they want. Rocky aims to be 1:1 exact with RHEL, and thus if there is no divergence, then we have to wait until RHEL release. We cannot anticipate and release something that is for example in CentOS Stream like Alma do because then we are no longer direct 1:1 with RHEL. Rocky has no aspiration to be ABI compatible, since that is not the same thing and as such may or may not be as stable as RHEL.
You have a free choice to use whatever distro you want.
I never blamed you. Since I’m a kernel noob but knew you were doing a 1:1 compatibility I assumed it was a mere copy paste of the fix, maybe some tests and then presto. I now know I was wrong.
Why do I have a recollection that Rocky did release some security fixed package (as “hotfix”) before RHEL (maybe a year ago)?
There are surely questions on how one gets access to the source to copy-paste, whether the paste is a trivial merge, and how thorough the “some tests” are. The only thing that we know definitely is that answer to first of those is different in Rocky and Alma.
I pay for neither distro and still (IMHO) get more than that “$0” worth.
I’m trying to find out from the team some more info on what we can do to speed it up. Eg: are we lacking people, or the automation isn’t doing what it’s supposed to, or the packages not been tested yet, or something else.
Some info from the infra team:
Had we been looking at standard basic packages, they would be happening quicker. When it’s reduced as per explained above, it’s gonna take a little longer. At least for the time being.
Now I am finally satisfied. Tonight, our automatic update routine pulled the new kernels kernel-4.18.0-553.74.1.el8_10.x86_64.
A reboot will follow later today.
Thank you for your efforts.
I do see the new kernel, but am curious if an erratum similar to https://access.redhat.com/errata/RHSA-2025:15471 is still in the works for https://errata.rockylinux.org/. And would adding the erratum also cause the new kernel to show up in the output of dnf updateinfowith the relevant advisory information?
Thanks,
Nick
Well, errata is another thing being worked on which you can follow the progress of here: Apollo, Errata, & You: a CIQ OSPO request for comment - #25 by sthornton
Lots of things to do.