CVE-2026-72379

/// Technical 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

/// Remediation

Check the references section for vendor advisories, patches, and mitigation guidance. If immediate patching is not possible, review the CVSS vector to understand the attack surface and apply compensating controls such as network segmentation or access restrictions.

/// References