CVE-2026-72379: fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid

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

fs: refuse OTMPFILE creation with an unmapped fsuid or fsgid

vfstmpfile() never checked that the caller's fsuid and fsgid map into the filesystem. On an idmapped mount whose idmapping does not cover the caller's fs{u,g}id, the ->tmpfile() instance initializes the new inode through inodeinitowner(), where mappedfsuid()/mappedfsgid() return INVALIDUID/INVALIDGID, and the tmpfile ends up owned by (uidt)-1.

Every other creation path already refuses this: mayocreate() (OCREAT) and maycreatedentry() (mkdir, mknod, symlink, link) bail out with -EOVERFLOW via fsuidgidhasmapping() precisely so that an object cannot be created with an owner the filesystem cannot represent. An OTMPFILE is no exception: it is created ILINKABLE and linkat(2) can splice it into the namespace afterwards, so the same guarantee must hold.

Add the missing fsuidgidhasmapping() check to vfstmpfile(). On a non-idmapped mount the caller's fs{u,g}id always map in the superblock's user namespace, so this is a no-op there and only takes effect on an idmapped mount that does not map the caller. It applies to every filesystem that sets FSALLOWIDMAP and implements ->tmpfile() (tmpfs, ext4, btrfs, xfs, f2fs, ...), and to overlayfs, whose upper-layer tmpfile creation funnels through vfstmpfile() via backingtmpfileopen().