Ubuntu's backports of CVE-2026-87766 fixes break Flatpak

Bubblewrap version: 0.9.0-1ubuntu0.2 (Ubuntu 24.04/noble-security) Flatpak version: 1.14.6 Distro: Linux Mint 22.2 (Zena), based on Ubuntu 24.04 noble Kernel: (7.0.0-31-generic)

Summary

After the CVE-2026-87766 security patches landed in bubblewrap 0.9.0-1ubuntu0.2 (importing safe_openat()/chroot_realpath() from crun, using openat2() with RESOLVE_IN_ROOT | RESOLVE_NO_MAGICLINKS), any flatpak app that requests CUPS/printing access (e.g. com.brave.Browser, org.mozilla.firefox) fails to launch with:

bwrap: Can't resolve /var/run/cups/cups.sock: Too many levels of symbolic links

Root cause

/var/run is a standard symlink to /run on this system (and most modern distros). The socket itself is healthy — confirmed via namei -l /run/cups/cups.sock (resolves cleanly to a proper socket, no loop) and findmnt/mountinfo (no duplicate or nested binds of /run). The failure only occurs inside bwrap's sandboxed resolution, not in a normal shell.

The new RESOLVE_IN_ROOT kernel resolution appears to treat crossing the /var/run → /run symlink boundary as a potential escape attempt, and the kernel reports this back as ELOOP (its generic refusal code), even though there is no actual symlink cycle — just one ordinary compatibility symlink that is extremely common across Linux systems.

Reproduction

On a system with CUPS running and /var/run symlinked to /run (default on Ubuntu/Debian/Mint): flatpak run com.brave.Browser Observe: bwrap: Can't resolve /var/run/cups/cups.sock: Too many levels of symbolic links

Workaround confirmed

Stopping CUPS (sudo systemctl stop cups.socket cups.service) allows the app to launch normally, confirming the CUPS socket bind-mount is what's tripping the new resolution path.

Impact

Any flatpak app with print permissions (which is most browsers and many desktop apps by default) fails to launch entirely on any system where CUPS is active and /var/run is a symlink to /run — which is the overwhelming majority of current Linux installs. This is a significant regression from a security patch that otherwise looks correct and necessary.

Could the RESOLVE_IN_ROOT resolution be adjusted to tolerate the standard /var/run → /run compatibility symlink (e.g. by canonicalizing well-known dual paths before resolution, or relaxing RESOLVE_NO_MAGICLINKS specifically for this known-safe case)? Happy to provide more diagnostic output if useful.