Exactly what I do, using Foreman Katello here.
@iwalker may i know is there a fix for Rocky Linux release 8.10 (Green Obsidian)
after the update I get to 4.18.0-553.120.1.el8_10.x86_64 #1 SMP Thu Apr 23 10:43:43 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux.
Should I just wait for the synch or there isnt a patch yet?
It should be fixed in 4.18.0-553.123.1.el8_10.x86_64 however this isnāt on the repo yet - only 553.120 is. So it will just be a question of waiting but it should appear soon - since EL9 and EL10 have been done.
I was about to post, 8 hasnāt been pushed out yet since itās not available to updateā¦so still waiting. Pretty sure itās just me and I appreciate all the work Rocky maintainers continue to do in order to support things but RHEL just moves way to slow to me. Obviously they felt this was not as urgent and maybe they thought that the interim solution was good enough but this should have been pushed out much faster, again imho. I was able to update most of my Debain based distroās on Friday and that is with Canonical being bombarded with a ddos attack. I had already migrated most of my RHEL servers due to them being asshats in regards to Centos etc, and this has just moved up migrating the rest of the servers that I have. Again I appreciate all the work that has gone into Rocky just tired of RHEL and what they have becomeā¦
What seems to me would be a win/win solution would be to have a second repo for high risk unofficial patches so that the user can decide to enable it or not. It would only contain high risk non RHEL packages that have not been patched by upstream yet. Once they are, the version numbers would be higher for the official package and you would get that.
I guess a problem though is that testing would fall heavier on rocky for those so there would be more work for the rocky maintainers than normal package releases from upstream. There is never infinite resources.
8.* kernel update just hit the repos for me and I was able to updateā¦just fyiā¦
That would be the most obvious solution for me as well. I fully expected a complete, 1:1, bug-for-bug coherence with RHEL when I went into Rocky, so having to wait for a patch to flow downstream is part of that expectation. But I understand why someone would want critical patches rolled out before RHEL gets to it.
So it feels like an extra repo would give both groups what they want with minimal worry. Doesnāt really matter if itās opt in or out, as long as thereās some way to control what youāre getting.
But honestly I would be completely fine with Rocky not supplying extra patches as well. Itās kinda what we signed up for here
Why havenāt you replied to me? Could you please tell me if you are not affected?
@quncetec , Go to https://errata.rockylinux.org/ and search for the CVE in question for your Rocky Version. Your question along with future similar questions will be answered there.
It was fine in this case because there was a mitigation available. A security hole of this severity should have a much faster response if this was not the case. Although I guess one could argue that if there was no good mitigation, the entire supply chain would have moved faster here. But still, the potential for an extremely unpleasant security hole dropping again in the future means to me that the option should be available if required. Maybe they set up an āurgentā repo and never use it for five years, but Iād argue thatās still better than needing it at some point and not having it in place.
And, if you believe the hype about LLMs being used to find new zero day vulnerabilitiies, we may begin to see things like this one happening more often. (I generally donāt believe AI hype; but one of the few areas LLMs are actually not terrible is in narrow rigidly defined information spaces, e.g. coding.)
I agree fully that this is what i signed up for. and feel the same as you do There was a mitigation for it so that likely weighed heavily for Red Hat as for how much testing would be done/delay before releasing as well as Rocky deciding to wait for RHEL packages. If we could have an option to enable another repo for very high severity stuff that might save some servers from being attacked though, That I think would be beneficial. If that emergency breaking of 1:1 is in-line with the goal of Rocky Linux though is the real question. Up until this point, I assumed was not the goal and 1:1 was the goal.
I think the bigger question is why did Red Hat take so long to release patches? If it were released several days ago, rocky would have got it maybe a day later.
Maybe it just takes that long for them to test all of their variations to meet their expected quality. Maybe some other reason good or bad. Hopefully this is the exception but if this is going to be the norm for RHEL for a high severity issue like this, then maybe having a separate repo for those that want to allow a break for 1:1 for very high severity vulnerabilities that RH taking too long for, would be beneficial to many users. Yes you could use a mitigation, but there will always be some systems that are not got to in time where an emergency update might have saved a system.
Lots of things to think about that though. Do rocky developers always jump on trying to patch very high severity stuff and abort it if RH gets it out before they do? Do Rocky devs wait hours day/days before putting effort in? Lots of details to think about I think that would really need to be defined to know what the actual bar is that is trying to be set to make sure that bar is being met consistently. Or just keep it 1:1 and know that is what we signed up for too.
Rocky aims to be 1:1 with RHEL, which has always been the case since the beginning. This is why updates, etc are usually 24-48 hours after being released by RH. If Rocky was to go off and do itās own thing, then it would be ABI compatible like Alma, etc. ABI compatible isnāt the same as being 1:1 since package versions, patches etc could vary in an ABI compatible distro so it will be slightly different but as close as it is willing to get. If Rocky was to diverge from aiming to be 1:1 with RHEL, then it would no longer be the same as what it was meant to be. No different than Alma, or using CentOS Stream as the whole idea was to be a stable distro like what the original CentOS was.
The ideal compromise is the extra repo for anyone who wants to temporarily run the fixed package until the RHEL fix is released. You can later remove that package or upgrade/downgrade it to the offcial one in the main repositories and return to being 1:1.
Obviously that last part is missing right now which would solve situations whereby the Rocky team could then offer something in the interim period to fix a potential security issue or risk with an affected package.
Right, I probably didnāt make that entire post clear. My context with that question in that post was if they were to start patching the most critical issues if RH doesnāt get them out in a decent time frame, What would that look like? It wasnāt insinuating that they should do that or that they do it now. I fully understand that the intent was 1:1 and what I signed on for. That example was the worst case scenario which I fully did not intend them to do if they did decide to patch more severe vulnerabilities when RH seems to take longer than expected.
I think that is a result of using Python < 3.10. If you (sudo) dnf install python3.11 (or python3.12), and make sure the line invoking Python reads python3.11 or python3.12 instead of just python3, it will āworkā again if vulnerable.
I would personally just do (sudo) grubby --update-kernel=ALL --args=initcall_blacklist=algif_aead_init I guess man grubby for details (donāt take my word for it, understand it). I do that on PowerEdges with --args=video=1024x768 so that when I log into the iDRAC, the whole remote screen fits on my local screen.
Thank you very much. I have upgraded to the specified kernel version(5.14.0-611.54.1.el9_7.x86_64). Would it be sufficient to upgrade to that kernel version? Is there any way to verify that the threat has been fixed?
I have used (not very precise, butā¦)
rpm -q --changelog kernel | grep 31431
# uname -a
Linux 12-19-rl96 5.14.0-611.54.1.el9_7.x86_64 #1 SMP PREEMPT_DYNAMIC Tue May 5 16:52:47 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
# rpm -q --changelog kernel | grep 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}
# id testa
uid=1001(testa) gid=1002(testa) groups=1002(testa)
# sudo su - testa
$ id
uid=1001(testa) gid=1002(testa) groups=1002(testa)
$ python3.11 copy_fail_exp.py
Password:
# id
uid=0(root) gid=0(root) groups=0(root)
@carlo Iāve just tried that on Rocky 9 with python 3.13 and it asks me for a password. Same kernel version as you. Maybe your user testa is added to sudoers and is allowed access without having to provide a password? Just guessing. But either way, the new kernel doesnāt allow it which suggests something with your system is wrongly configured.
The user testa is a regular user with a password set, but not configured in the sudoers file.
# cat /etc/sudoers | grep testa
# ls /etc/sudoers.d/
#
@carlo As mentioned, I guessed at sudoers, but also if you already used sudo as testa user, the password is remembered. Subsequent sudo doesnāt ask again for the password. Either way, the problem doesnāt exist in this kernel as Iāve already tested and cannot replicate it. Therefore, the problem is with your server or current session and not the kernel. Could be testa has been added to wheel group, or other config options that you will need to check out. But as far as I see the problem is not the kernel, otherwise I would be able to replicate it, which I cannot.