Note that it is only URGENT security patches that will be pushed.
Hopefully visibly tagged so that you can opt out easily, and versioned so that the next upstream update automatically applies.
The survey provides two options: âFor urgent security updates to Rocky Linux, ahead of updates in RHEL, would you prefer they be âdefaultâ (in the normal repositories) or require manual intervention to install (in a separate repository)?â
Option 1 - currently at 67%, is that taking no action, hosts will automatically get Urgent security patches outside the Upstream. There is no easy way to Opt-Out.
Option 2 - Currently at 33% would place Urgent security patches in a separate repo which you can opt in to, If you point your hosts at this repo, you would automatically get these. A simple Opt-In.
I feel strongly that Option 2 is the best for my use case. I also believe that most will agree when considering it outside the current panic this particular CVE has triggered.
Embedded in the exploit is a ELF binary compiled for x86_64. For the exploit to work on aarch64, you would need to swap in a aarch64 binary with the same functionality.
âAhead of updates in RHELâ. Well, that is not this update, clearly, since RHEL10 has a patch and Rocky 10 doesnât.
But I also have a hard time imagining what youâd need to reach that level of urgency, given that this instant easy escalation to root does NOT reach that level.
Iâm not going to say that there is no reason for someone to have a policy of wanting to delay such urgent patches. If theyâre not my systems itâs not my policy and I shouldnât dictate.
But I WILL say two things. First anyone with such precise and specific needs can already take control of their update process in ways that ensures significant updates donât come as a surprise.
And second, the poll seems to be creating a false dichotomy by ignoring compromise solutions. For example: create an âUrgentâ repo. Enable it by default. Anyone who doesnât want it can disable it. But those with more generic policy requirements almost certainly will want that to be enabled.
Red Hat just published them yesterday or the day before, as I only got those updates myself yesterday for RHEL. So 24-48 hours and it will be available in Rocky, as the work on that started yesterday either today or tomorrow it should be available.
The poll was created to see if Rocky want to push patched kernels to the default repositories so that nobody needs to enable something additional, or to have them in separate repositories that would need to be enabled. For example, get an existing kernel, and patch it and bump the release number so that itâs available in the default repositories. Or by pushing kernel versions with patches like they did with OpenSSL in a separate repository temporarily so that people can pull it if they want from additional repositories, before official patches appear just like the RHEL ones just published in the normal repositories.
Both options are valid depending on which way you look at it. Some may want from the default repos, others may prefer the additional repos to enable. Obviously if you donât enable them, then you donât get the fix. So at that point, if itâs enabled by default, it may as well just be patched in the normal base repositories without creating an additional repo.
We got the update today, it looks like the debacle is over. How do we undo the mitigation now? 
grubby --update-kernel=ALL --args="initcall_blacklist="
that doesnât remove the argument, just empties it.
this should remove the workaround GRUB options:
grubby --update-kernel=ALL --remove-args="initcall_blacklist=algif_aead_init"
I swear I looked before asking, but I didnât see --remove-args. Thanks! 
Update done with dnf update --refresh
Thanks to the team at Rocky Linux for the quick response!
Iâve run dnf update --refresh on Rocky Linux 10.1, but the exploit still works even after reboot.
Have you tried re-running the exploit?
Is there a specific repository I need to enable to get the patch?
If youâre using a 3rdparty mirror, thereâs a possibility that mirror is lagging behind a bit (this just happened for me with a swedish mirror). Browsing through the repo here it looks like 10.1 got a new kernel package last night, however I canât see the changelog now to verify the patch(es) is in place.
Adjust your yum.repos.d-repo file for baseOS repo and make sure youâre using the main dl.rockylinux.org mirror for this update. If you have dnf-plugins-core you can use dnf changelog kernel to make sure.
5.14.0-611.49.1.el9_7.x86_64 Will this kernel version be affected?
Yes, because itâs fixed in 5.14.0-611.54.1.el9_7.x86_64
@Alexandre I 100% agree with @filuur that it is probably an issue where the âlocalâ mirror you are using has not updated. On my Rocky 9 test box i had to go and disable the mirrorlist option for the base repo and use the baseurl pointing direct to the rocky DL link to validate before pulling the patched kernel into our central patch management tool, I did run the exploit test again and confirmed that SU prompted for root password now instead of just granting root access.
If you do not have the DNF module enabled for changelog you can validate via rpm example from my test rig:
rpm -q kernel --changelog| grep -i cve-2026-31431
- crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption (Vladislav Dronov) [RHEL-172201] {CVE-2026-31431}
- crypto: algif_aead - Revert to operating out-of-place (Vladislav Dronov) [RHEL-172201] {CVE-2026-31431}
for RHEL10 (https://access.redhat.com/errata/RHSA-2026:13566) the patched kernel version is kernel-6.12.0-124.55.1.el10_1.x86_64.rpm that is now available for Rocky 10 - Rocky Linux Repository
You can try:
sudo dnf clean all
sudo dnf makecache
sudo dnf update
Hello, i cleaned all cache, but the latest kernel available for me is
[12:58:17] [root@server ~]# dnf update kernel
Last metadata expiration check: 0:01:51 ago on Wed May 6 12:56:28 2026.
Dependencies resolved.
Nothing to do.
Complete!
[12:58:19] [root@server ~]# dnf info kernel
Last metadata expiration check: 0:01:57 ago on Wed May 6 12:56:28 2026.
Installed Packages
Name : kernel
Version : 5.14.0
Release : 570.49.1.el9_6
Architecture : x86_64
Size : 0.0
Source : kernel-5.14.0-570.49.1.el9_6.src.rpm
this is strange, because iâm in 9.7
[12:59:06] [root@server ~]# cat /etc/os-release
NAME="Rocky Linux"
VERSION="9.7 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.7"
Just wait for the mirrors to sync and then you will get it. If everybody switches to baseurl then the main Rocky mirror gets overloaded, and then nobody can download anything.
Mirror syncing is likely being delayed because the filelist files on msync.rockylinux.org havenât been updated since May 3rd and the blessed mirror script depends on those files being updated.
If everybody switches to baseurl then the main Rocky mirror gets overloaded, and then nobody can download anything.
I feel like this is a very good opportunity to point out/remind (at least for those of us that run medium/large fleets) that itâs very easy to set up your own local mirror and keep that in sync with one of the public mirrors. It takes very little time to set up and helps out a ton by taking unecessary load off public mirrors.