The official Red Hat response: cve-details
They say this may impact functions that use kernel cryptographic functions. For what it’s worth, the initcall_blacklist=crypto_authenc_esn_module_init is the one that made is so the released exploit python script didn’t work any longer YMMV.
To explain what you saw, rmmod attempts to remove a kernel module from your running system. It fails because that particular code is not a module on Rocky systems. Also, therefore the mitigation being suggested, dropping a configuration (.conf) file into /etc/modprobe.d, won’t work either, as what that tries to do is prevent the module from loading (returns nonzero to whatever invokes it, that’s what /bin/false does). Since, as above, on Rocky systems it’s “baked into” the kernel (and not a module), that technique is ineffectual.
This exploit seems using /usr/bin/su. The immediate way may be simply to change it to be root readable only on the server. Any thoughts?
It may be more accurate to say “the exploit DEMO appears to be using /usr/bin/su”
Which may be the case; I haven’t looked at it myself but I’m prepared to take your word for it.
But that likely wouldn’t exclude there being (many?) other ways to get there as well.
The exploit works with ANY setuid program. su is just an example.
It’s actually even worse, doesn’t even need to be a setuid program
Can also be a regular file that has serious implications for being changed, like /etc/passwd
I am wondering why it takes so long for rhel releasing patches.
Debian trixie was fixed around 10h after bug publication, testing even earlier. Bookwom is now patched too!
Ubuntu has additional mitigation packages:
https://ubuntu.com/blog/copy-fail-vulnerability-fixes-available
What am I missing here in the rhel strategy for this critical issue?
So far, the only option is a manual mitigation, something a lot of people may not be doing, especially over the weekend. 
Hello guys,
RHEL don’t move on this subject.
AlmaLinux team publish a patch. Maybe can you redistribute it ?
Best regards,
Detailed info directly relevant for Rocky Linux: Mitigating CVE-2026-31431 on Rocky Linux 8, 9, 10, and LTS Variants | CIQ Knowledge Base
Great !
Is a fix for Rocky 8 is in progress ?
Thanks !
Hi,
Could you please confirm whether a fix for Rocky Linux 8 is also currently in progress for CVE-2026-31431?
Given that Rocky Linux 8 is still widely deployed in production environments, it would be helpful to know whether a patched kernel is planned.
Thanks.
If you are on Rocky 9.3 or newer you need to add --update-bls-cmdline to grub2-mkconfig:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg --update-bls-cmdline
Do we have a patch for latest supported Rocky 9.7 ? Any idea when it is planning to be released?
Do this patch available in rocky8.10?
Why is it taking so long? Other Linux distributions have already released the new bug-fix kernels, but Rocky Linux still hasn’t been patched. This is the first time I’ve truly felt that Rocky Linux users are in the minority.
