Is NixOS affected by Dirty Frag

Help
1

Another distro-agnostic Local Privilege Escalation exploit has been crafted and released, this time before the kernel upstream has released a patch. It’s called Dirty Frag and it’s leveraging 2 similar vulnerabilities, affecting kernel modules esp4 esp6 and rxrpc

I’m starting this topic to consolidate discussion about Dirty Frag. I am far from an expert on linux kernel exploitation or even NixOS, but I’m learning by running it on my main PC, so I would appreciate community input on options for mitigation and updates as true patches become available.

6 Likes
2

It seems like the patch has been merged AFTER the last kernel release, so you have to either fetch the patch in boot.kernelPatches or blacklist the modules for now.

For example, to blacklist these -

{ pkgs, ... }:

{
  boot.extraModprobeConfig = ''
    install esp4 ${pkgs.coreutils}/bin/false
    install esp6 ${pkgs.coreutils}/bin/false
    install rxrpc ${pkgs.coreutils}/bin/false
  '';
  boot.blacklistedKernelModules = [
    "esp4"
    "esp6"
    "rxrpc"
  ];
}
9 Likes
3

These somewhat-exotic-module exploits keep popping up, and I wonder if we should start recommending security.lockKernelModules instead of (or in addition to; nothing wrong with defense in depth) playing whack-a-mole with each newly exploited module.

(I learned about this option from the now-deleted hardened profile, and even though knowledgeable people described it as an unmaintained mess, I continue to think that it’s a shame that tricks like that now have to be found individually by NixOS users who join us after the deletion.)

8 Likes
4

The modules_disabled sysctl is definitely the way to go instead of “playing whack-a-mole” as you said. Users should explicitly declare the modules they wish to load in initrd.

2 Likes
5

Example how the Patch could look like:

boot.kernelPatches = [
    {
      name = "dirty-frag";
      patch = pkgs.fetchurl {
        url = "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4";
        hash = "sha256-j5l548aKMPIxfSfwy4hJadBvQN2kZsutpOVjLSXSk0A=";
      };
    }
  ];
6

There are fix kernel releases for 6.6 and newer for the first vulnerability (xfrm-ESP, CVE-2026-43284). We merged them now and Hydra build them currently. You can track the progress using the following links:

Unstable: https://nixpk.gs/pr-tracker.html?pr=517962

Stable (25.11): https://nixpk.gs/pr-tracker.html?pr=517981

The second vulnerability (RxRPC, CVE-2026-43500) has fixes now (as of 2026-05-11):

Unstable: https://nixpk.gs/pr-tracker.html?pr=518947

Stable (25.11): https://nixpk.gs/pr-tracker.html?pr=517864

10 Likes
7

Just tried this on my VPS, worked with surprisingly few problems, though dhcpcd does seem to need af_packet - worth noting when reconfiguring machines one doesn’t have console access to :)

1 Like
8

Well, we could add e.g. a wiki page with these recommendations. Profiles are simply no longer the way to go, because once imported, there is no good way to disable certain things from the profile again in an easy way. Take a look at e.g. GitHub - cynicsketch/nix-mineral: Conveniently and reasonably harden NixOS. · GitHub if you’re looking for things you could configure to harden your system.

3 Likes
10

Yes, I see that NixOS Hardening - Official NixOS Wiki has this option among others! (But if the profile had maintenance issues, it seems unlikely that the wiki page is better in that respect, unless edits to that page are being watched by security professionals more closely than PRs to the hardened profile were.)

A profile is just a module; it sets options, and users can override those option values if they want (as I did for years, since the memory allocator set by the hardened profile caused me problems). In principle, the only difference between a project like nix-mineral and a theoretical better hardened profile is that the profile isn’t a third-party product.

2 Likes