I've always though that the more popular linux becomes, the more vulnerabilities it will expose.
this post was submitted on 30 Apr 2026
235 points (98.8% liked)
Selfhosted
58910 readers
572 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 posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
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 2 years ago
MODERATORS
Basically every server runs linux already, so it's already a big target
And also "Good. If they're found they'll be patched. Worry about the ones that 'aren't' 'found.'"
Honestly, if an attacker has shell access you're toast regardless. I know you shouldn't be able to escalate privileges, but better to never let them on the machine.
Most security in industry only holds because employees have no interest in attacking, or knowledge how to attack, their employer.
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.
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.
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".
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.
Looking at the binary blob, it's a payload to assume privileges as possible and exec sh. So replace su with that and the binary gets to use su's filesystem privileges without needing access to actually write it.
The vulnerability part is when the door opens to replace any file's read cache with arbitrary content. The binary payload is just an obvious example of the sort of payload that could do a ton of damage.
load more comments
(1 replies)
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
Looking at the CVE on NIST,i found following commit which dates to 30.03
the debian cve tracker also links to that page, but they have written 7.0-rc7 besides it.
https://security-tracker.debian.org/tracker/CVE-2026-31431
the openwall link has some comments that talk about the delayed patches, Greg KH also commented.
7.0-rc7 is probably due to the 7.0 release early mid april. So the fix was in the mainline on 1st of April. The commit on 11th from GKH was probably due to the release.
I am not that familiar with the commit and release structure to get more into detail. But to me it clearly looks like the statement on copy.fail is correct, that the fix was in mainline on 1st of April.
From my point of view, I would suggest that maybe the communication downstream to the distros was not handled that well? But who would be to blaim? The researches that would need to communicate this issue to most existing distros? Linux maintainers? Distro maintainers?
Hard to say, without knowing the communication of the related mailinglists and disclousre etc.
For my trixie Debian boxes I just did a normal apt upgrade, rebooted, checked the kerenel with uname -r and 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 |
| HTTP | Hypertext Transfer Protocol, the Web |
| LTS | Long Term Support software version |
| NAS | Network-Attached Storage |
| nginx | Popular HTTP server |
4 acronyms in this thread; the most compressed thread commented on today has 10 acronyms.
[Thread #267 for this comm, first seen 1st May 2026, 10:50] [FAQ] [Full list] [Contact] [Source code]
That's a good bot!
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 -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 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_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.
load more comments
(1 replies)
load more comments
(5 replies)
I ran the script today and my system is vulnerable.
Cachyos, all up to date.
load more comments
(2 replies)
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.
load more comments
(1 replies)
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
Do you have a source for how often it happens or is this conjecture? I guess this would most often happen through supply chain attacks or physical access, the first not being all that common in my understanding and the latter not being a typical threat model for a home computer. But if you have a source explaining what actually happens, I would love to read it.
There are plenty of way to get a local unprivileged shell
For instance, if you are running a old version of cups someone could chain together several vulnerabilities to gain root on your system
Having a MAC like SELinux helps to mitigate this but you still should patch as soon as possible
load more comments
(3 replies)
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
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 su but I don't fully understand the AF_ALG and authencesn bug limits things, or what other executables can escalate privileges.
load more comments
(2 replies)
load more comments
(2 replies)
This doesn't affect my org at all. Our SAAS providers already demand ssh root access on our Linux VMs so their applications work.
view more: next ›