CVE-2026-72379 in Linux
Summary
by MITRE • 08/15/2026
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().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/15/2026
The vulnerability described represents a critical privilege escalation issue within the Linux kernel's virtual file system layer. This flaw exists in the handling of temporary file creation operations through the O_TMPFILE flag, which allows applications to create temporary files without immediately linking them into the filesystem namespace. The core technical problem occurs in the vfs_tmpfile() function that fails to validate whether the caller's filesystem user and group identifiers can be properly mapped within the target filesystem's context, particularly on idmapped mounts where such mapping may not exist.
The vulnerability stems from inconsistent security checking between different file creation pathways within the kernel's VFS implementation. While other creation operations like O_CREAT through may_o_create() and mkdir/mknod/symlink/link through may_create_dentry() properly enforce filesystem mapping validation via fsuidgid_has_mapping() checks that return -EOVERFLOW when mapping fails, the O_TMPFILE path completely bypasses this critical validation step. This omission allows malicious actors to create temporary files with invalid ownership identifiers, specifically UID/GID values of -1 (INVALID_UID/INVALID_GID) when filesystem mappings are incomplete or absent.
The operational impact of this vulnerability extends across multiple filesystem types that support the FS_ALLOW_IDMAP flag and implement the ->tmpfile() operation, including tmpfs, ext4, btrfs, xfs, f2fs, and overlayfs. When an application attempts to create a temporary file on an idmapped mount where the caller's fs{u,g}id cannot be properly resolved within the filesystem's namespace, the system creates an inode with invalid ownership that could potentially be exploited for privilege escalation or denial of service attacks. This issue is particularly dangerous because O_TMPFILE files can be made I_LINKABLE and subsequently linked into the namespace via linkat(2), maintaining the security vulnerability throughout the file lifecycle.
This vulnerability maps directly to CWE-250, which covers "Execute Code with Unusual or Unexpected Privileges," and aligns with ATT&CK technique T1068, "Exploitation for Privilege Escalation." The fix implements a straightforward but critical security check by adding fsuidgid_has_mapping() validation to vfs_tmpfile(), ensuring that temporary file creation behaves consistently with other file creation paths. On non-idmapped mounts, this check becomes a no-op since the caller's fs{u,g}id always maps within the superblock's user namespace, maintaining backward compatibility while adding protection specifically for idmapped mount scenarios where the security boundary is more complex.
The mitigation strategy requires updating the vfs_tmpfile() function to perform the same validation that already exists in other creation paths, ensuring that any attempt to create temporary files on idmapped filesystems fails gracefully with -EOVERFLOW when the caller's identifiers cannot be properly mapped. This approach maintains consistency with existing kernel security patterns and prevents the creation of potentially exploitable temporary files with invalid ownership identifiers across all affected filesystem implementations while preserving normal operation on standard mount configurations.