CVE-2026-74618: binfmt_misc: don't warn when the mount is completed from another user namespace

In the Linux kernel, the following vulnerability has been resolved:

binfmtmisc: don't warn when the mount is completed from another user namespace

fsopen() records the caller's user namespace in fc->userns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIGCMDCREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket.

Completing a context from another user namespace is allowed on purpose. vfscmdcreate() authorizes the create with mountcapable(), which for FSUSERNSMOUNT checks nscapable(fc->userns, CAPSYSADMIN), and that succeeds for a task holding CAPSYSADMIN in an ancestor of fc->userns. So an unprivileged task can reach the WARNON() in bmfillsuper(): create a user and a mount namespace in a child, call fsopen("binfmtmisc") there, send the fscontext fd to the parent and let the parent issue FSCONFIGCMDCREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere:

WARNING: fs/binfmtmisc.c:938 at bmfillsuper+0xa2/0xc0 [binfmtmisc] CPU: 15 UID: 1000 PID: 3243382 Comm: fswarn Call Trace: gettreekeyed+0x7d/0xb0 bmgettree+0x34/0x90 [binfmtmisc] vfsgettree+0x2a/0x100 vfscmdcreate+0x60/0xf0 dosysfsconfig+0x4b2/0x500

The child needs the mount namespace because fsopen() itself gates on maymount(), which asks for CAPSYSADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check.

It is a WARNON() and not a WARNONONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with paniconwarn.

Keep refusing the mount and stop warning about it. Nothing in bmfillsuper() depends on the two namespaces matching, it derives everything from sb->suserns.