It affects any device that can use raw sockets in the kernel. Patch everything.

What do you mean? If you use Linux on your computer, it's also relevant. Any program can quietly drop a root shell from any privilege level in 10 lines of python.

Yea I didn't think the post was that professional. Also the "unminified" version is just the minified with more white space. It still has poor names and no explanation of the binary blob.

The patches where proposed over a month ago and the patch to the kernel was commited on 1th of April.

Either the Vulnerability was not proper communicated to the distro maintainers or they were the ones sleeping.

This was probably executed as a responsible discllsure where clear timelines and release dates get communicated from the beginning.

I find it hard to blame the security team here when there was 1 month of time between first commited patch and release of the PoC.

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.

Check uname -r

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 ran the script today and my system is vulnerable.

Cachyos, all up to date.

Basically every server runs linux already, so it's already a big target

Honestly, thats a really bad take. Yes obviously, you should not let attackers access the terminal, but there are linux servers that rely on multiuser operations, like Servers that are meant for terminal access, like HPC.

Then services get hosted via container these days, so even with rootless containers you get root access if you only get RCE on one service. And even if there are additional VMs for more isolation between host, you still get root on the whole VM.

Note that this is a rather narrow view of the scope of things.

Yes, the demonstrator is a python script that opens up 'su' and uses splice+this vulnerability to change it to 'just assume all privileges and become sh'.

However, it's that any process in any namespace can leverage a certain socket type and splice to effectively modify any filesystem content they want. It's easy to see how this could be part of a chained attack to, for example, replace a protected service that is firewalled off with a shell. An RCE in a service permits rewriting nginx in an entirely different container and replaces it with a shell backend of your choosing.

That 'flatpak' application on your single user system that is guarded from touching your files that aren't related? That isolation doesn't mean anything if this issue is in play.

In terms of shared systems, while it should be avoided if possible, practically speaking there's a lot of shared resources.

I don't get why I've seen so many people saying "ehh, no big deal, privilege escalation is just a fact of life".

I work for a critical, global communications infrastructure company, and it's painfully obvious that the moment someone has a foothold they could do whatever they want with some minor skill lol.

Probably looks more 1337 this way 🤣

There's a readable version in the issues, tho: https://github.com/theori-io/copy-fail-CVE-2026-31431/issues/54#issuecomment-4351460190

I don't think af_alg is exposed to non-root users on android.

This is a kernel bug, unattended-upgrades will take care of installing the new kernel once the fix is published, but you still have to reboot to load it. I've set up a cron job that runs needrestart nightly and reboots my servers if there is a pending kernel upgrade [1]

That's a good bot!