---
id: CVE-2026-72379
title: 'fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid'
summary: |-
  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 mo…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 <
    74365c6e367725728d5ce36d38ca116c9f77a254
  - >-
    Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 <
    bac8fb0d60254846f3b56957435dcd870ae12948
  - >-
    Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 <
    503d0568a525b168d9aa5ca046ec72fc5477df84
  - >-
    Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 <
    a2038514e69371eb493083a6a897ed20fcbb8acb
  - >-
    Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 <
    47e434da476b5a8bcd1e6e52ab03c5ee7764ee78
  - >-
    Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 <
    539dce1144651f7976fa418e618b0b574bf15eeb
  - Linux 5.13
published: '2026-08-15'
updated: '2026-10-30'
sourceUpdated: '2026-10-30T12:29:11.407Z'
source: CVEORG
sourceUrl: 'https://www.cve.org/CVERecord?id=CVE-2026-72379'
references:
  - url: 'https://git.kernel.org/stable/c/74365c6e367725728d5ce36d38ca116c9f77a254'
  - url: 'https://git.kernel.org/stable/c/bac8fb0d60254846f3b56957435dcd870ae12948'
  - url: 'https://git.kernel.org/stable/c/503d0568a525b168d9aa5ca046ec72fc5477df84'
  - url: 'https://git.kernel.org/stable/c/a2038514e69371eb493083a6a897ed20fcbb8acb'
  - url: 'https://git.kernel.org/stable/c/47e434da476b5a8bcd1e6e52ab03c5ee7764ee78'
  - url: 'https://git.kernel.org/stable/c/539dce1144651f7976fa418e618b0b574bf15eeb'
tags:
  - cve.org
epss: 0.00215
epssPercentile: 0.1196
ingestedAt: '2026-11-05T15:02:32.510Z'
---

## Overview

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

## Affected

- `Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 < 74365c6e367725728d5ce36d38ca116c9f77a254`
- `Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 < bac8fb0d60254846f3b56957435dcd870ae12948`
- `Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 < 503d0568a525b168d9aa5ca046ec72fc5477df84`
- `Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 < a2038514e69371eb493083a6a897ed20fcbb8acb`
- `Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 < 47e434da476b5a8bcd1e6e52ab03c5ee7764ee78`
- `Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 < 539dce1144651f7976fa418e618b0b574bf15eeb`
- `Linux 5.13`

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.