Does this affect Synology NASs?
This disclosure has been rushed for the views and hype IMO, none of the big distros had fixes ready to go on this this morning.
Nothing much to do for me. Just apply patches as normal.
Edit: I wonder how bad is it on Android
I wished android is affected but no
I don’t think af_alg is exposed to non-root users on android.
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?
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
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~~
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
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
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.
I haven’t checked too deeply but I think fedora dropped the affected system between kernels 6.6 and 6.12 somewhere. 6.12+ appear to not have the modules.
Not too surprising given the system has been deprecated for a long time.Interesting enough systems running SELinux seem to be potentially protected against this assuming SELinux is configured to block AF_ALG
On Android AF_ALG is locked down with SElinux so it shouldn’t be impacted
Why is the PoC obfuscated?
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
This doesn’t affect my org at all. Our SAAS providers already demand ssh root access on our Linux VMs so their applications work.
For a second I though this was something bad for my computer. But is mainly a server permissions issue it seems. Will patch my server when I’m home though
It affects any device that can use raw sockets in the kernel. Patch everything.
“mainly”, it is a ‘lower’ priority for single use local computers
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.
This attack must be run locally. The attacker must already have user access. They can then escalate privileges using this. Meaning your box must already be compromised for this to work. Still serious, but no need to panic in most cases.
A local compromise happens more than you think
/c/selfhosted moment
Sure don’t patch a quiet and easy root shell escalation because it is, by itself, not a remote exploit. I sure do hope you trust every single piece of software running on your computer.
I think you’re displaying a very big gap between understanding risk assessment and understanding task completion. So far I have not seen anyone say they would not complete the task. I have seen people complete risk assessment. Risk assessment does not mean I will not do something, it just reflects the urgency with which I will do it. Most self-hosted users can safely apply basic risk assessment to see, while the impact may be high, the likelihood is low. Obviously the likelihood increases the more hands off you are with, say, unattended container updates for things that can escape containers or access the underlying system. Should most self-hosted users literally drop everything, rush home, and apply the patch? No, basic risk assessment does not merit that. Should everyone apply the patch? Yes.
Disable the sandbox bit and it’s bobbitted, right ?
I have a mix of Debian and Ubuntu servers. I’ll update manually anyway but for future cases, would unattended-upgrades set to security upgrades run daily be enough to stop this type of issue?
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]
Unattended-upgrades has a config option to auto reboot
laughs in unattended-updates. On Debian, not Crapuntu
will it reboot to apply the kernel changes?
