Has the recently found copy.fail exploit been addressed in Truenas?

TrueNAS General
, , ,
1

When can we expect emergency fixes?

2 Likes
Patch your servers, peeps, new COPYFAIL Linux kernel vulnerability just dropped
2

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.

3 Likes
3

As a security dude, the only thing that really panics me is RCE’s, especially zero touch remote control exploits. Locals, just be careful internally.

2 Likes
4

From my understanding, Docker/Kubernetes-based apps can be points of exploitation as well.
Code execution inside a container/app can also be local code execution against the host kernel, because containers share the host kernel.

Kubernetes / container clusters

The page cache is shared across the host. A pod with the right primitives compromises the node and crosses tenant boundaries.

cross-container, cross-tenant

2 Likes
5

LOL, In general, only authorized people should be gaining root access as well. This CVE bypasses that “requirement”.

2 Likes
6

Unfortunately kernel updates on Truenas seems to have a late train systematically. Personally after verification, I have Truenas version 25.10.3 but the installed kernel is 6.12-33 while it takes version 6.12-85 to get the patch of the fault :scream:

7

What bothers me:

TrueNAS isn’t advertized as a specialized fileserver appliance only. A growing part of the featureset is being a full-fledged virtualisation platform. And for a fault this big and this public and this easily exploiable I’d expect them to issue a fix (which does exist and just needs to be applied) within hours and not days or weeks. Even Microslop knows this.

1 Like
8

Yes.

My comment was local access. Meaning code has to be loaded locally. Then run locally. Yes, containers could either be Trojaned or such that remote attackers could log in.

Individual users of TrueNAS need to determine if such are possible / likely, and what immediate temporary mitigation is desired, needed or required.

For the moment, we don’t know which work around actually works. Black listing a loadable module that does not exist, (because the code is builtin to the kernel), does nothing. However, their is a kernel command line that appears to work in that case. Yet, we don’t know if that affects SSH, SSL / TLS or ZFS dataset encryption on TrueNAS.

9

Kernel newbie question: wouldn’t this flaw allow any of the hundreds of apps in the TrueNAS catalog to - if compromised - allow root access to the entire box?

2 Likes
10

If you haven’t seen this thread yet.

11

Please do monitor our security site for updates on this and other security topics:

7 Likes
Patch your servers, peeps, new COPYFAIL Linux kernel vulnerability just dropped
12

Glad to know that 25.10.3.1 will patch this!

3 Likes
13

If attackers are so far into your infrastructure that they can make use of a privilege escalation attack like this, you have a problem much bigger than this vulnerability.

Coincidentally, this is one of the reasons why I always recommend not exposing your services externally, all it takes is a different vulnerability in your exposed app that lets an attacker run arbitrary code and that’s that. Your choice to expose the services directly basically invite attackers to your front door where they can lie in wait for the perfect storm of arbitrary code execution + privilage execution.

2 Likes
14

Indeed it is. Though the follow-up question is when 25.10.3.1 will ship–I’d expect soon, but it’d be nice to see something definite on that question.

Somewhat unfortunate that they aren’t backporting the fix to any earlier release, though, especially since “mission critical” users are still advised to be on 25.04.

2 Likes
15

Thanks for confirming that TrueNAS includes, but does not use, the AF_ALG module, and providing the appropriate mitigation:

Mitigation pending kernel update:
midclt call system.advanced.update '{"kernel_extra_options":"initcall_blacklist=algif_aead_init"}'
then reboot. Mitigation persists across reboot

Do I understand correctly that the fix will ONLY be in 25.10.3.1, so users of 25.04 and earlier will have to upgrade?

1 Like
16

From my limited understanding of the issues involved, I was thinking along the lines of someone compromising an app from the catalog and using that as a jumping-off point for the rest of the system. In this case one wouldn’t have, I believe, to expose anything externally.

I am not very concerned, as I don’t use anything other than the Tailscale app (and that for remote admin only), but with more than 360 apps currently and Docker being exploitable, I can’t help but wonder.

3 Likes
17

The exploit requires local execution, so something has to be exposed.
Pure storage use does not require shell access for anyone but the administrator—so no issue here, if the attacker has the admin password Copyfail is not even needed.
Concerns come with running apps on top of the storage. If an app can be leveraged to run code for the user, it could carry a Copyfail attck (the ArsTechnica discussion proposed exploiting a Wordpress plugin to run data as user “www-data” as an example). TrueNAS is not hardened for Internet exposure, so the attack would still have to come from someone inside your network/organisation (or someone who has the Tailscale credentials to access remotely).

3 Likes
18

You can check the mitigation by running the CVE-2026-31431 (“Copy Fail”) Toolkit available at rootsecdev/cve_2026_31431: Exploit POC for CVE_2026_31431

truenas_admin@truenas[~]$ curl https://raw.githubusercontent.com/rootsecdev/cve_2026_31431/refs/heads/main/test_cve_2026_31431.py | python3
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100  7810  100  7810    0     0  19905      0 --:–:-- --:–:-- --:–:-- 19872
[*] CVE-2026-31431 detector  kernel=6.12.33-production+truenas  arch=x86_64
[+] AF_ALG + ‘authencesn(hmac(sha256),cbc(aes))’ loadable - precondition met.
[!] VULNERABLE to CVE-2026-31431.
[!]   Marker b’PWND’ (AAD seqno_lo) landed in the spliced page-cache page at offset 0.
[!]   Surrounding bytes: 50574e444641494c2d53454e  (b’PWNDFAIL-SEN’)
[!] Apply the upstream fix or block algif_aead immediately.

truenas_admin@truenas[~]$ midclt call system.advanced.update ‘{“kernel_extra_options”: “initcall_blacklist=algif_aead_init”}’
{“id”: 1, “advancedmode”: false, “autotune”: false, “kdump_enabled”: false, “boot_scrub”: 7, “consolemenu”: true, “consolemsg”: false, “debugkernel”: false, “fqdn_syslog”: false, “motd”: “Welcome to TrueNAS”, “login_banner”: “”, “powerdaemon”: false, “serialconsole”: false, “serialport”: “ttyS0”, “anonstats_token”: “”, “serialspeed”: “9600”, “overprovision”: null, “traceback”: true, “uploadcrash”: true, “anonstats”: true, “sed_user”: “USER”, “sysloglevel”: “F_INFO”, “syslogservers”: 
, “syslog_audit”: false, “isolated_gpu_pci_ids”: 
, “kernel_extra_options”: “initcall_blacklist=algif_aead_init”}

truenas_admin@truenas[~]$ curl https://raw.githubusercontent.com/rootsecdev/cve_2026_31431/refs/heads/main/test_cve_2026_31431.py | python3
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
Dload  Upload   Total   Spent    Left  Speed
100  7810  100  7810    0     0   148k      0 --:–:-- --:–:-- --:–:--  149k
[*] CVE-2026-31431 detector  kernel=6.12.33-production+truenas  arch=x86_64
[+] Precondition not met (‘authencesn(hmac(sha256),cbc(aes))’ cannot be instantiated (No such file or directory)). NOT vulnerable.

`

19

I’m here for this. block the module, carry on. Since the vulnerability is part of a module (some other distributions compile it built-in), preventing it from loading is a solution. No need to worry about forcing an OS update just for it if the exploit is already entirely inert.

The solution i added to my server is adding a file /etc/modprobe.d/cve-2026-31431.conf with the contents:

install algif_aead /bin/true

That doesn’t just blacklist it from the system autoloading it but blocks it from manually loading it too. Of course, I haven’t checked that it persists in a reboot for TrueNAS, but I’ll live.

Cheers!

20

Reminder: The TrueNAS “native” mitigation is a midctl call which was posted above; this will persist after reboot and update.

2 Likes