CVE Catalog

CVE-2026-72379

Low risk· EPSS 11%
Published: Updated: Translated: NVD NIST

Exploitation Probability (EPSS)

Low risk
0.21%

11th percentile - higher than 11% of all known CVEs

Summary

In the Linux kernel, vfs_tmpfile() does not check whether the caller's fsuid and fsgid map into the filesystem. On an idmapped mount that does not cover the caller, a new temporary file (O_TMPFILE) is created with owner (uid_t)-1, which is incorrect. Other file creation paths already perform this check.

Risk Assessment

Possibility to create a temporary file with an invalid owner, which could lead to permission issues and potential security breaches. The file can later be linked via linkat(2), increasing the risk.

Recommendation

Apply the kernel patch that adds the fsuidgid_has_mapping() check to vfs_tmpfile(). Update your system to a kernel version with this fix.

Other vulnerabilities in Linux kernel

See all
Original NVD description (English source)

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().

Vulnerability data from NVD (NIST) · CISA KEV · EPSS