Probably mirrors haven’t synced yet:
dnf clean all
dnf update
I just browsed online the Rocky mirror and the 553.124 kernels are there.
Never mind, I can see a newer version: 4.18.0-553.124.1.el8_10. Does it have the fix?
You can check it:
dnf changelog kernel
and see what it says. If not, then install the one from security repo.
From what I see you need the kernel from security:
Changelogs for kernel-4.18.0-553.124.1.el8_10.0.2.x86_64
* Mon May 18 12:00:00 AM 2026 Jonathan Dieter <jdieter@resf.org> - 4.18.0-553.124.1.0.2
- ptrace: slightly saner 'get_dumpable()' logic (Roxana Nicolescu) [ciqres] {CVE-2026-46333}
- sched: fix exit_mm vs membarrier (v4) (Roxana Nicolescu) [ciqres] {CVE-2026-46333}
* Thu May 14 12:00:00 AM 2026 Jonathan Dieter <jdieter@resf.org> - 4.18.0-553.124.1.0.1
- net: skbuff: propagate shared-frag marker through frag-transfer helpers (Hyunwoo Kim) [ciqres] {CVE-2026-46300}
An update to my earlier post on this topic. The errata covers all the normal repositories and this is where you will find all the info related to that. The way it runs at the minute is it’s one set of updates behind and they are working on fixing this. For now, releasing 9.8 and 10.2 has a higher priority, but at some point the errata will be more up-to-date.
For the security repo there won’t be errata because there is no point. These are only temporary fixes until the official fixes arrive from RHEL. Had RHEL released fixes far quicker, then the security repo wouldn’t have been required at all, and therefore nothing extra would need doing.
We’ve enabled the security repo, but some of our devices are only updating to:
kernel.x86_64 5.14.0-611.55.1.el9_7.0.1 @security
Instead of 5.14.0-611.55.1.el9_7.0.3. We’ve tried a dnf clean, looking at the rpm log 7.0.1 doesn’t remediate CVE-2026-46300. How can we force an update to 5.14.0-611.55.1.el9_7.0.3?
Was fixed in this kernel:
root@rocky9:~# dnf changelog kernel | grep -B2 -A3 46300
* Thu May 14 12:00:00 AM 2026 Jonathan Dieter <jdieter@resf.org> - 5.14.0-611.55.1.0.2
- net: skbuff: propagate shared-frag marker through frag-transfer helpers (Hyunwoo Kim) [ciqres] {CVE-2026-46300}
- Drop rxrpc patches since upstream has decided not to carry them. Users of kernel-modules-partner are now
vulnerable to CVE-2026-43500, but the package is only available in the unsupported devel repo
as for not seeing the new kernel you are prob hitting a mirror that hasn’t synced yet. So it’s either a case of waiting or:
dnf clean all
dnf update
but again, based on mirrorlist it could be hit and miss until you hit a good mirror.
root@rocky9:~# uname -r
5.14.0-611.55.1.el9_7.0.3.x86_64
-
8.10: ≥kernel-4.18.0-553.124.1.el8_10.0.2
-
9.7: ≥kernel-5.14.0-611.55.1.el9_7.0.3
-
10.1: ≥kernel-6.12.0-124.56.1.el10_1.0.3
@iwalker Rocky Linux Repository
There is no corresponding kernel update available in the Rocky Linux 8.10 repository.
only have kernel-modules-4.18.0-553.124.1.el8_10.x86_64.rpm
don’t have kernel-modules-0:4.18.0-553.125.1.el8_10.x86_64.rpm
Red Hat Enterprise Linux 10.1 was updated on 2026-05-20, but Rocky Linux 10 has not yet synchronized the corresponding update.
@Sky you will need to enable security repo. Then once done you will see kernel-4.18.0-553.124.1.el8_10.0.2.x86_64.rpm where it has been fixed. As for the latest official RHEL kernel in 8.x it probably hasn’t hit yet because the team are busy working on releasing 9.8 and 10.2.
Thank you for the reply. From the beginning, I noticed the Security repository and appreciated the community’s quick response to vulnerability fixes. This approach gives users confidence.
My current question is that RHEL has already released the update and published the advisory indicating the issue has been fixed. Rocky Linux 8.10 also published the corresponding security advisory:
However, the corresponding updated kernel package does not appear to be available in the repository yet.
And again as I said, the Rocky team is busy releasing 9.8 and 10.2. So if the 8 package hasn’t appeared yet, then it will in due course. A lot of this information is already explained on the Rocky Wiki here: Rocky Linux Release and Version Guide - Rocky Linux Wiki and there are no ETA’s - they will be when they will be. It’s fixed already in the kernel in the security repo, which also makes it less urgent in pushing out the other 8.x kernel so I don’t see what the problem is? But as already said, it will be soon. If there is anybody who cannot accept that situation or are impatient, then perhaps they should be paying for RHEL? RH has a far bigger team than Rocky, so this needs to be understood. Not only that, kernel’s need to be signed, so requires someone to do that. And if the team is busy doing other things, then it’s a case of waiting.
I see in koji that the kernel for RL8 was built on May 21, yet, 6 days later, it’s still not in the repos. I think it’s fair to wonder if there was an error or something got stuck somewhere.
kernel-4.18.0-553.125.1.el8_10 | Build Info | Rocky Linux Build Service
To restate the concern in case there is confusion: The Rocky Linux (not RHEL) errata page (RLSA-2026:19666) announcing updated packages was released six days ago but the packages announced therein as available are not, in fact, available.
At some point, if this persists, someone is going to need to verify that this is just a case of the devs being busy. Apologies if that has already been verified, but initial posts about this being the case used the word “probably”. . . with no explicit verification since.
Meanwhile, a whole slew of other errata docs were just published. . . and those package are available immediately, as you’d expect.
I could indeed be wrong, but my own instincts are telling me that this is not a case of “the devs are too busy to do it” but is instead a “devs already did it and something in the publishing pipeline has glitched out” situation.
P.S. I have already used the security repo for high-risk hosts. Its existence won’t “unstuck” whatever may in fact be stuck, however. 