What channel do you build from? What commit? And what kernel package are you using?
nixos-25.11, kernel version 6.12.47, should be came from here nixpkgs/pkgs/os-specific/linux/kernel/linux-rpi.nix at 755f5aa91337890c432639c60b6064bb7fe67769 · NixOS/nixpkgs · GitHub
2 Likes
NixOS stable ships with the old stable kernel 6.12.
I am a bit surprised that according to package search
the default kernel is still on version 6.12.83. But the patch is only in 6.12.85 (changelog) or newer. When should we expect the update with the patch in the default NixOS kernel?
It’s been 2.5 days since the fix was backported to the 6.12 branch.
Last I checked the update to .85 was already merged, it’s just a matter of making it through CI…
Just checked again, and the patches looks like they’ve hit unstable, as well as stable-small, but we’re still waiting on stable, as of this writing.
6 Likes
Just checked again, even master branch only use kernel version 6.12.75
Is it save to manually bump this number and built kernel from source? Last time I use kernel other than rpi4 kernel the box cannot boot up, so I am afraid it will happen again.
Just an update: the new kernel version has now hit stable.
As mentioned above, though, this only applies if you use the main kernel builds. Special builds like rpi4 are a different story.
7 Likes
Hi, I am running a 25.05 system what kernel version should I update to? Is 6.18.22 compatible with 25.05?
Update to 25.11. 25.05 has been EOL for several months. It no longer gets security updates.
4 Likes
To explain further,
- The releases are in YEAR.MONTH format
- Releases happen every May and November
- You have a month after a new stable release to upgrade
So you should have been using nixos-25.11 since December 2025, at least.
And now since it’s this late, you should be preparing to upgrade to nixos-26.05 (slated to release end of this month), in fact.
4 Likes
ok i mischaracterized it. if i understand it correctly, the contents of /run/current-system/sw/bin/su must be the same as the executable /run/wrappers/bin/su, but not just the content, but it must actually point to the same exact content of the same “file” or location (sorry, not sure which abstraction level has the correct terminology here), not a copy with identical content.
if this is the case, when changing the page cache for the readable /run/current-system/sw/bin/su, it actually has effect on executing the binary /run/wrappers/bin/su (which has setuid for root), so that the system reads the same page cache. and this fact of being the exact same content at the same location is apparently the case on nixos, hence, the exploit with my code snippet indeed works on nixos.
or am i still explaining it incorrectly?
Oh, I think you’re missing that /run/wrappers/bin/su is… a wrapper 
It doesn’t have identical contents, or refer to the same underlying file, or anything like that. It’s a binary wrapper that does execve("/path/to/the/real/su", ...). i.e. NixOS doesn’t ever give the su binary itself setuid; it calls it from a generic wrapper setuid binary. The reason the vulnerability works by messing with the /run/current-system/sw/bin/su binary and not /run/wrappers/bin/su is because, although the attacker can’t affect the wrapper binary’s contents / behavior, that binary still ends up calling out to the non-setuid su binary that the attacker can affect.
2 Likes
I didn’t see this CVE (cve-2026-31431) listed in https://tracker.security.nixos.org/
And I can’t find a reference to it in the Nixpkgs issues: Issues · NixOS/nixpkgs · GitHub
Is that simply because no-one thought to link it?
I thought there might be an automated system that tracks repos / versions used in nixpkgs, tracks the CVE list, and automatically adds linked security issues.
It looks like the security tracker does not match kernel CVEs, I’m guessing it’s because the name of our kernel packages.
Is that simply because no-one thought to link it?
I thought there might be an automated system that tracks repos / versions used in nixpkgs, tracks the CVE list, and automatically adds linked security issues.
Yeah most likely. They are just too many kernel CVEs to keep track, the only sustainable way is to keep updated at all time. Same issue for the browsers really.
1 Like
if i understand correctly we are not yet represented at the distros mailing list. i wonder if we might not already satisfy their criteria?
1 Like
I think [this argument]( Vulnerability Notifications for NixOS - #4 by vcunat ) (current infra does not support private builds while a vuln is under embargo) still holds.
1 Like