CVE-2026-74483: binfmt_misc: don't leak the user namespace when the mount fails

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

binfmtmisc: don't leak the user namespace when the mount fails

bmgettree() takes a reference to the user namespace and hands it to gettreekeyed() as the sget key. sgetfc() moves that reference into sb->sfsinfo and clears fc->sfsinfo, so from that point on the superblock owns it and bmfree() doesn't see it anymore.

The superblock drops it in ->putsuper(). But genericshutdownsuper() only calls ->putsuper() from inside the if (sb->sroot) branch, so nothing releases it when bmfillsuper() fails:

- The kzallocobj() failure leaves sroot NULL and the whole branch is skipped.

- A simplefillsuper() failure in the file loop leaves sroot set, but sop still points at simplesuperoperations, which has no ->putsuper(). bmfillsuper() installs sops only once simplefillsuper() returned success, and installing it earlier wouldn't help either because simplefillsuper() overwrites sop.

Either way vfsgetsuper() calls deactivatelockedsuper() and the reference is gone for good. binfmtmisc mounts are available in a user namespace and both the inode and the dentry cache are SLABACCOUNT, so an unprivileged caller under a tight memory cgroup can fail simplefillsuper() on demand and leak one user namespace per attempt.

Drop the reference in ->killsb() instead, which runs unconditionally, the same way nfsd and rpcpipefs release their keyed sfsinfo.

That also stops ->putsuper() from clearing sfsinfo while the superblock is still on @fssupers. genericshutdownsuper() leaves it there on purpose so that sgetfc() keeps finding it until killsb() has run, but a NULL sfsinfo makes testkeyedsuper() miss it, so a concurrent mount for the same user namespace skips the grabsuper() wait and creates a second superblock for a namespace that is still being torn down.