For my trixie Debian boxes I just did a normal apt upgrade, rebooted, checked the kerenel with
uname -rand confirmed it was 6.12.85-1. All set!Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters Git Popular version control system, primarily for code LTS Long Term Support software version NAS Network-Attached Storage
3 acronyms in this thread; the most compressed thread commented on today has 7 acronyms.
[Thread #267 for this comm, first seen 1st May 2026, 10:50] [FAQ] [Full list] [Contact] [Source code]
is custom kernels safe?
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.
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.
tbh they could have boasted even less bytes by just having everything in a zlib.decompress()
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.
and the patch to the kernel was commited on 1th of April.
are you sure? what I have seen in git patch dates is 11th for the unreleased 7.0, and yesterday for the LTS versions
Does this affect Synology NASs?
Probably. But it’s unlikely to be exploited as the attack needs shell access for the bad operation, not just any buffer.
Nothing much to do for me. Just apply patches as normal.
Edit: I wonder how bad is it on Android
Android doesn’t have
su, which this proof of concept exploit requires. Although rooted Android does, so in theory malware written for rooted Android could escalate to root privileges.Also, the underlying vulnerabilities might be exploitable without
subut I don’t fully understand theAF_ALGandauthencesnbug limits things, or what other executables can escalate privileges.I don’t think af_alg is exposed to non-root users on android.
I wished android is affected but no
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~~
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.
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.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.
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
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
Every time I see people boasting about their uptime, I ask myself how old their kernel actually is.
I’ve set this auto reboot and never had to worry about patching my server.
Edit: yeah I know live patching is a thing, not worth the hassle for 99% of server workloads.
Disable the sandbox bit and it’s bobbitted, right ?
