CVE-2026-72379None▾ SunlitIn 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…
▾ Sunlit zone — Low / medium · no exploitation signal
impact 2.8 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Nov 5.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via CVEORG
Last analysed / modified upstream
0.2%
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().
Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 < 74365c6e367725728d5ce36d38ca116c9f77a254Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 < bac8fb0d60254846f3b56957435dcd870ae12948Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 < 503d0568a525b168d9aa5ca046ec72fc5477df84Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 < a2038514e69371eb493083a6a897ed20fcbb8acbLinux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 < 47e434da476b5a8bcd1e6e52ab03c5ee7764ee78Linux >= 8e5389132ab429604c1a2459b52f0c849a71cc61 < 539dce1144651f7976fa418e618b0b574bf15eebLinux 5.13Refer to the linked advisories for vendor-supplied fixes and affected version ranges.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-99284Nonenet: skbuff: propagate shared-frag marker in skb_zerocopy()
CVE-2026-99283Nonenetfilter: conntrack: tcp: use UNACK timeout for non-closing RST packets
CVE-2026-99272Nonesmb: client: validate the data area in SMB2_read()
CVE-2026-99271NoneALSA: line6: Clear prev_fbuf on capture buffer release
CVE-2026-99273Noneksmbd: reserve space for the UTF-16 terminator in stream info
CVE-2026-99275Nonesmb: client: reject short SESSION_SETUP responses