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

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

From: Greg Kroah-Hartman <gregkh@kernel.org>

Description
===========

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

fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid

vfs_tmpfile() 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 inode_init_owner(), where mapped_fsuid()/mapped_fsgid() return
INVALID_UID/INVALID_GID, and the tmpfile ends up owned by (uid_t)-1.

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

Add the missing fsuidgid_has_mapping() check to vfs_tmpfile().  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 FS_ALLOW_IDMAP and implements ->tmpfile() (tmpfs,
ext4, btrfs, xfs, f2fs, ...), and to overlayfs, whose upper-layer
tmpfile creation funnels through vfs_tmpfile() via backing_tmpfile_open().

The Linux kernel CVE team has assigned CVE-2026-72379 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 5.13 with commit 8e5389132ab429604c1a2459b52f0c849a71cc61 and fixed in 6.6.145 with commit bac8fb0d60254846f3b56957435dcd870ae12948
	Issue introduced in 5.13 with commit 8e5389132ab429604c1a2459b52f0c849a71cc61 and fixed in 6.12.97 with commit 503d0568a525b168d9aa5ca046ec72fc5477df84
	Issue introduced in 5.13 with commit 8e5389132ab429604c1a2459b52f0c849a71cc61 and fixed in 6.18.40 with commit a2038514e69371eb493083a6a897ed20fcbb8acb
	Issue introduced in 5.13 with commit 8e5389132ab429604c1a2459b52f0c849a71cc61 and fixed in 7.1.5 with commit 47e434da476b5a8bcd1e6e52ab03c5ee7764ee78
	Issue introduced in 5.13 with commit 8e5389132ab429604c1a2459b52f0c849a71cc61 and fixed in 7.2-rc2 with commit 539dce1144651f7976fa418e618b0b574bf15eeb

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2026-72379
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	fs/namei.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/bac8fb0d60254846f3b56957435dcd870ae12948
	https://git.kernel.org/stable/c/503d0568a525b168d9aa5ca046ec72fc5477df84
	https://git.kernel.org/stable/c/a2038514e69371eb493083a6a897ed20fcbb8acb
	https://git.kernel.org/stable/c/47e434da476b5a8bcd1e6e52ab03c5ee7764ee78
	https://git.kernel.org/stable/c/539dce1144651f7976fa418e618b0b574bf15eeb