I’m still learning about this, but I didn’t see it here, so..
Most Linux LPEs need a race window or a kernel-specific offset.
Copy Fail is a straight-line logic flaw — it needs neither.
The same 732-byte Python script roots every Linux distribution shipped since 2017.
Ughh - I really wasn’t looking forward to updating. Anything specific or we waiting for IX to release a hotfix?
Kernal updates are the only fix. It’s a nasty one. There’s a mitigation out there that I’m applying to some AWS VPS servers I have, but I’m on Debian, so you’ll have to check for your flavor. And take this with a grain of salt as it’s too early to know if these mitigations are 100%. All info provided for amusement and research.
Summary of Risk
Scenario Risk Level
App is patched, Kernel is unpatched Moderate (Requires an unknown bug in the app first).
App is unpatched, Kernel is unpatched CRITICAL (Total home lab takeover in minutes).
App is exposed, Kernel is patched Low (Attacker stays trapped in the app/container).
1. Apply the "Zero-Downtime" Mitigation
This is the most critical step for your home lab and VPS. It disables the specific kernel interface (AF_ALG) that the exploit uses. This does not break standard encryption like SSH, VPNs, or LUKS; it only blocks userspace apps from asking the kernel to do crypto work via a socket.
Run these two commands on every machine (VPS and home servers):
Bash
# Block the vulnerable module from being loaded
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-copyfail.conf
# Remove it from memory immediately
sudo rmmod algif_aead 2>/dev/null || true
…and really it shouldn’t be; security vulns should be reported privately, directly to iX.
There was another thread posted about it, just an hour or so ago, but I don’t see it now–perhaps it’s been deleted for that reason. (Edit: no it wasn’t; I just overlooked it: Has the recently found copy.fail exploit been addressed in Truenas?)
And yes, I know the vuln is pretty public at this point, so this caution might be moot–but it’s still good practice.
If not mistaken it is near 0-day for every flavour of linux & publicly available & publicly documented. I think the forums is a safe bet.
Edit: you edited that you understand it is public knowledge right after I replied - so my reply is pretty moot as well 
I’m aware of the practice, but seeing as “The same 732-byte Python script roots every Linux distribution shipped since 2017.,” I felt it warranted a post. Spooking IX customers has to take a back seat on this one. EVERYONE with ANY device, embedded, mobile, etc. running Linux is vulnerable. My Cuisenart K-Cup maker might go offline tomorrow.
If this doesn’t get ya scratchin’ the ol’ noggin’..
Clarify.. this will affect any system, embedded, mobile, server, toy, etc. that has
any form of Linux running after 2017
Yes, that is a precise and sobering assessment. Because the vulnerability lies within the Linux Kernel’s Crypto API, specifically a logic error in how it handles memory buffers during encryption/decryption tasks, the “blast radius” includes almost everything running a modern Linux kernel.
The reason the date 2017 is cited is that the specific code path responsible for this flaw was introduced in Kernel version 4.14, which was released in late 2017.
Why this is uniquely dangerous
Usually, vulnerabilities are confined to a specific application (like a browser or a web server). This is at the kernel level, which is the “God mode” of the operating system.
Embedded & IoT: Your smart home hubs, network switches, and even some smart appliances run stripped-down Linux kernels. Gas pumps, signs, security systems, alarms, cameras, the list is VAST. Most of these never get updates. If they are accessible on your network, they are now permanent “root-access” entry points for an attacker.
Mobile (Android): Android is built on the Linux kernel. Any Android device running a kernel version between 4.14 and the latest 6.x builds is theoretically vulnerable to local privilege escalation. A malicious app (even one without special permissions) could use CopyFail to take over the entire phone.
Toys & “Black Boxes”: Devices like retro-handhelds, “smart” toys, or even some automotive head units use Linux. If they have any form of connectivity (Wi-Fi/Bluetooth), they are at risk.
Virtualization (The Proxmox/Cloud Factor): On your home servers or VPS, this isn’t just about one OS. Because the guest OS (a Docker container or a Linux VM in some configurations) shares or interacts with the host’s kernel, an attacker can move “upward” from a restricted container to the physical hardware.
The “AF_ALG” Problem
The flaw is triggered via the AF_ALG socket interface. This interface was designed to allow “User Space” (your apps) to use the “Kernel Space” (the OS’s high-speed crypto engines).
By sending a specifically malformed request to this socket, an attacker triggers a buffer overflow that allows them to overwrite kernel memory with their own code. Since the kernel has the highest possible permissions, once that memory is overwritten, the system is fully compromised.
Summary of Impact
Servers: High risk due to multi-tenancy and internet exposure.
WSL2: High risk because it bridges your Windows files to the Linux kernel.
IoT/Embedded: The "Silent Risk" because these devices are rarely patched by the manufacturer.
Mobile: Critical risk if you sideload apps or use third-party app stores.
*STAY FROSTY!*In any event, the affected kernel module isn’t used, at least in 25.10.3:
Welcome to TrueNAS
Last login: Thu Apr 30 16:34:31 2026 from 192.168.1.141
root@truenas[~]# lsmod | grep algif
root@truenas[~]#
Just because the module isn’t loaded now doesn’t mean a clever attacker (who gets a shell via a Docker container or an app like Plex/Nextcloud) can’t load it themselves.
To move from “the module isn’t active” to “the module is banned,” you should blacklist it. Can this be done? I’m not sure. Does it need to be done? Probably.
# This creates a rule that prevents the module from ever loading
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/block-copyfail.conf
echo "install algif_hash /bin/false" | sudo tee -a /etc/modprobe.d/block-copyfail.conf
echo "install algif_skcipher /bin/false" | sudo tee -a /etc/modprobe.d/block-copyfail.conf
# Update the initramfs to make it stick across reboots
sudo update-initramfs -u`
For any server accessible from the internet that has an app exposed. If that “one app” is running on TN (via a custom Docker container, jail, vm, etc.), it shares the same kernel as the ZFS file system.
If an attacker uses that app to trigger the kernel to load algif_aead, they go from “Web User” to “Root of the NAS” in seconds. By blacklisting it as shown above, you ensure that even if they try to call that module, the system simply says “Access Denied.”
I’m off to mitigate. Good luck folks!
Keep in mind that this might be built into the kernel.
I poked around my desktop, and could not find this algif_aeadas a module. Or even as a configuration parameter for my kernel. This desktop uses 6.18.18, which is supposed to be vulnerable.
To let those who don’t know, this exploit requires local access first. In general, only authorized people should be logging into a TrueNAS server via Shell. (Of course, I will upgrade all my Linux computers, but no hurry from me…)
Fixed in:
7.0+
6.19.12
6.18.22
6.12.85
6.6.137
6.1.170
5.15.204
5.10.254
I second the OP’s comments and they have done wonderfully at explaining things.
The negligence in the comments from people so far in this thread are astonishing but maybe that’s just me and this is normal form this forum (this is the first thing I’ve come to this forum about). It’s like I found another sub-reddit.
Good to know, whew, agreed, and me too (in that order).
That said, I did run those shell commands just in case.
From this post and the link, the “TrueNAS way” of mitigation is:
midclt call system.advanced.update '{"kernel_extra_options":"initcall_blacklist=algif_aead_init"}'
Would need a reboot afterwards or?
And reboot indeed.
And user accounts never become compromised, right…? Relying on users and user accounts to keep your system(s) safe is not wise.
Further, it’s only been proven that a local user login can be used. That does not prove that there are no other alternate attack vectors.
My $0.02: it is a vulnerability that requires very little effort on my part to mitigate. I understand that on its own it would require some form of local access, however, I don’t understand the full potential of this vulnerability + any other(s) used in conjunction. Therefor, I’ll spend the minor amount of effort to mitigate it.