GHSA-XPVR-4R6X-X86M
Vulnerability from github – Published: 2026-08-15 06:32 – Updated: 2026-08-15 06:32In 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": [],
"aliases": [
"CVE-2026-72379"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-15T06:22:11Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid\n\nvfs_tmpfile() never checked that the caller\u0027s fsuid and fsgid map into\nthe filesystem. On an idmapped mount whose idmapping does not cover the\ncaller\u0027s fs{u,g}id, the -\u003etmpfile() instance initializes the new inode\nthrough inode_init_owner(), where mapped_fsuid()/mapped_fsgid() return\nINVALID_UID/INVALID_GID, and the tmpfile ends up owned by (uid_t)-1.\n\nEvery other creation path already refuses this: may_o_create() (O_CREAT)\nand may_create_dentry() (mkdir, mknod, symlink, link) bail out with\n-EOVERFLOW via fsuidgid_has_mapping() precisely so that an object cannot\nbe created with an owner the filesystem cannot represent. An O_TMPFILE\nis no exception: it is created I_LINKABLE and linkat(2) can splice it\ninto the namespace afterwards, so the same guarantee must hold.\n\nAdd the missing fsuidgid_has_mapping() check to vfs_tmpfile(). On a\nnon-idmapped mount the caller\u0027s fs{u,g}id always map in the superblock\u0027s\nuser namespace, so this is a no-op there and only takes effect on an\nidmapped mount that does not map the caller. It applies to every\nfilesystem that sets FS_ALLOW_IDMAP and implements -\u003etmpfile() (tmpfs,\next4, btrfs, xfs, f2fs, ...), and to overlayfs, whose upper-layer\ntmpfile creation funnels through vfs_tmpfile() via backing_tmpfile_open().",
"id": "GHSA-xpvr-4r6x-x86m",
"modified": "2026-08-15T06:32:22Z",
"published": "2026-08-15T06:32:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72379"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/47e434da476b5a8bcd1e6e52ab03c5ee7764ee78"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/503d0568a525b168d9aa5ca046ec72fc5477df84"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/539dce1144651f7976fa418e618b0b574bf15eeb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a2038514e69371eb493083a6a897ed20fcbb8acb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bac8fb0d60254846f3b56957435dcd870ae12948"
}
],
"schema_version": "1.4.0",
"severity": []
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.