DevOps & Administration, TrueNas

CopyFail CVE-2026-31431 and the TrueNAS Workaround

CopyFail has been all over the Linux security news lately, and for good reason. The vulnerability is tracked as CVE-2026-31431 and properly described in this blog post -> Copy Fail — CVE-2026-31431

And this one is not the usual “technically serious, but probably not relevant for my homelab” kind of bug.

CopyFail is a Linux kernel local privilege escalation vulnerability in the algif_aead / AF_ALG crypto path. The public write-up describes it as a reliable way for an unprivileged local user to get root by abusing AF_ALG, splice(), and a controlled 4-byte page-cache write. The researchers also published a small Python proof of concept, so this is not just a theoretical issue. theori-io/copy-fail-CVE-2026-31431: Copy Fail (CVE-2026-31431): 9-year-old Linux kernel LPE found by Theori’s Xint Code

Why this matters for TrueNAS

TrueNAS SCALE is Linux-based, so kernel issues matter.

For a pure storage appliance where nobody except the admin has shell access, the practical risk is lower. Copy Fail is not a remote exploit by itself. An attacker first needs local code execution on the system.

But TrueNAS is not always “just storage” anymore.

Many setups run:

  • Apps
  • Containers
  • VMs
  • Self-hosted web services
  • Backup tools
  • Monitoring agents
  • Tailscale or other remote-access helpers

And containers share the host kernel. So if a compromised app or container can execute code locally, a kernel local privilege escalation becomes much more interesting. This was also discussed in the TrueNAS community thread: code execution inside a container can still become code execution against the host kernel because the kernel is shared.

So no, this does not mean “everyone on the internet can instantly root your TrueNAS”.

But also no, this is not something I would personally ignore.

The workaround on TrueNAS SCALE

iXSystem has a temporary mitigation until a fixed kernel is available. See https://security.truenas.com/link/?reference=CVE-2026-31431

Open the TrueNAS shell and run the following bash command then reboot.

Bash
midclt call system.advanced.update '{"kernel_extra_options": "initcall_blacklist=algif_aead_init"}'

Testing whether the workaround actually does something

After applying a mitigation, I usually want one boring thing: proof that the box behaves differently afterwards.

For CopyFail, there is a public detector script on github rootsecdev/cve_2026_31431: Exploit POC for CVE_2026_31431 that checks whether the vulnerable AF_ALG AEAD path can be reached. I ran it on the TrueNAS shell before applying the workaround:

Small note here: piping random code from GitHub directly into Python is not exactly best practice. For a quick lab check, fine. On anything important, download the script first, read it, verify where it comes from, and then run it. Security testing by blindly executing internet scripts is how you accidentally create a second blog post.
Bash
curl https://raw.githubusercontent.com/rootsecdev/cve_2026_31431/refs/heads/main/test_cve_2026_31431.py | python3

And the result was not exactly comforting but expected:

Bash
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.

That is a pretty clear “yes, this system has the affected code path available”.

The TrueNAS workaround is to add a kernel boot parameter that prevents algif_aead from being initialized:

Bash
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 accepted the setting and showed it in the advanced system config:

Bash
"kernel_extra_options": "initcall_blacklist=algif_aead_init"

Important: this is a kernel boot option, so you should reboot before trusting the mitigation state.

After rebooting, I would first confirm that the option is actually active:

Bash
cat /proc/cmdline

You want to see this somewhere in the output:

Bash
initcall_blacklist=algif_aead_init

Then run the detector again:

Bash
curl https://raw.githubusercontent.com/rootsecdev/cve_2026_31431/refs/heads/main/test_cve_2026_31431.py | python3

This time the result changed:

Bash
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.

That is the result I wanted to see.

The detector is not saying “your kernel is patched”. It is saying the vulnerable precondition is no longer reachable because the affected AEAD algorithm path cannot be instantiated anymore. For this workaround, that is exactly the point.

If the second test still says vulnerable, I would check three things:

  1. Did the system actually reboot?
  2. Does /proc/cmdline contain initcall_blacklist=algif_aead_init?
  3. Did TrueNAS preserve the kernel_extra_options value?

For my system, once the vulnerable algorithm could no longer be instantiated, the detector reported NOT vulnerable, which is good enough for me until the proper fixed TrueNAS kernel lands.

Things to keep in mind

This is a mitigation, not the final fix!

The real fix is a patched kernel. The Copy Fail site recommends patching first and explains that the upstream fix reverts the problematic algif_aead in-place optimization.

Also, disabling this interface should not affect the usual things most people worry about first, like LUKS, dm-crypt, SSH, OpenSSL, or normal TLS usage, because those generally do not rely on this userspace AF_ALG AEAD path. The CopyFail mitigation notes say the main possible impact is software explicitly configured to use AF_ALG.

My take

For me this falls into the category: Not panic, but patch or mitigate quickly.

If your TrueNAS box is only used as a storage appliance, has no exposed apps, no random shell users, and sits behind sane network boundaries, the immediate risk is probably manageable.

If you run apps, containers, CI jobs, web services, or anything that might process untrusted input, I would apply the workaround until the fixed TrueNAS release or kernel update is installed.

The command is simple, reversible, and directly targets the affected kernel initialization path.

So my current checklist is:

  1. Apply the workaround.
  2. Reboot.
  3. Confirm /proc/cmdline.
  4. Watch for the official TrueNAS kernel update.
  5. Remove the workaround later if TrueNAS recommends doing so after patching.

As always: don’t blindly copy commands from random blog posts. Read the official TrueNAS security response and check your own environment first.