So, there’s much to be said about these vulnerabilities…
https://guix.gnu.org/en/blog/2025/privilege-escalation-vulnerabilities-2025/

First, thanks to fellow Nix and Lix hackers for sending us a heads-up, for sharing Snyk’s detailed report, and for coordinating with us. 👍

Privilege Escalation Vulnerabilities (CVE-2025-46415, CVE-2025-46416) — 2025 — Blog — GNU Guix

Blog posts about GNU Guix.

The fix has been 3 months in the making (!) and that was far from trivial.

Reepca (whose review work on the rootless guix-daemon had been instrumental) has been doing almost all the development work in Guix.

It’s an impressive piece of work, including in terms of the size of the diff—the biggest in the entire history of ‘guix-daemon’.

Reepca will share their thoughts on this later, but it’s hundreds of lines of code 👇

25 files changed, 2855 insertions(+), 550 deletions(-)

… to “just” work around a couple of Linux design flaws.

We’re plugging a user-level network stack (slirp4netns) + namespaces + seccomp filters just because abstract Unix-domain sockets are (1) ambient authority in a global name space, and (2) associated with “network namespaces” instead of some IPC namespace.

It’s fundamentally wrong that we have to pull in so much additional code (that includes slirp4netns and seccomp) to plug the holes.
@civodul To be fair, the TOCTOU stuff is mostly a result of using paths instead of directory fds (known-broken for some 20 years). I do agree that it would be nice to have abstract unix sockets in ipc ns, but I can also see why they are in net ns, they are sockets after all.

@cancername Yeah, the TOCTOU issues is mostly addressed by the *at family of functions.

As for abstract Unix-domain sockets, I think they’re really local IPC; having them in the net namespace causes so much trouble.

@civodul ambient authority strikes again
@civodul excellent work. This is one reason why we should all be using free software. Thank you Reepca and Nix folks!

@civodul

Would have been nice to notify downstream providers of guix sometime during that 3 months...

Looking at the patches and they are really a bear to apply on top of the last released version of guix (~2.5 years old)... could really have used more time to backport them!

My wild guess is the awesome code to support running guix daemon as an unprivledged user (which is really important!) may be making backporting the patches much harder...

@vagrantc Yeah, apologies for not reaching out before. I think we generally try to improve our process for security updates and that is an obvious problem (another one being that too few people were involved and that it’s hard to get involved on embargoed issues).

It’s possible that the rootless daemon code makes things harder to patch indeed.

(But hear, hear, GCD 005 offers to schedule a release in the coming months!)