334
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 30 Apr 2026
334 points (98.3% liked)
Selfhosted
59955 readers
585 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam.
-
Posts here are to be centered around self-hosting. Please ensure it is clear in your post how it relates to self-hosting.
-
Don't duplicate the full text of your blog or git here. Just post the link for folks to click.
-
Submission headline should match the article title.
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 3 years ago
MODERATORS
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.