Katalog CVE

CVE-2026-72379

Niskie ryzyko· EPSS 11%
Opublikowano: Zaktualizowano: Przetłumaczono: NVD NIST

Prawdopodobieństwo exploitacji (EPSS)

Niskie ryzyko
0.21%

Percentyl 11 - wyżej niż 11% wszystkich znanych CVE

Streszczenie

W jądrze Linux funkcja vfs_tmpfile() nie sprawdza, czy identyfikatory fsuid i fsgid wywołującego są odwzorowane w systemie plików. Na zamontowanym systemie z mapowaniem ID (idmapped mount), które nie obejmuje wywołującego, nowy plik tymczasowy (O_TMPFILE) jest tworzony z właścicielem (uid_t)-1, co jest nieprawidłowe. Inne ścieżki tworzenia plików już to sprawdzają.

Ocena ryzyka

Możliwość utworzenia pliku tymczasowego z nieprawidłowym właścicielem, co może prowadzić do problemów z uprawnieniami i potencjalnego naruszenia bezpieczeństwa. Plik może być później podpięty przez linkat(2), co zwiększa ryzyko.

Rekomendacja

Zastosuj poprawkę jądra dodającą sprawdzenie fsuidgid_has_mapping() w vfs_tmpfile(). Zaktualizuj system do wersji jądra z tą poprawką.

Inne podatności w Linux kernel

Zobacz wszystkie
Oryginalny opis (angielski, źródło NVD)

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

Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS