CVE-2026-72379
Zusammenfassung
von VulDB • 15.08.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
fs: Verweigerung der O_TMPFILE-Erstellung bei nicht zugeordneter fsuid oder fsgid
vfs_tmpfile() hat niemals überprüft, ob die fsuid und fsgid des Aufrufers in das Dateisystem abbildbar sind. Bei einem idgemappten Mount (idmapped mount), dessen ID-Zuordnung die fs{u,g}id des Aufrufers nicht abdeckt, initialisiert die ->tmpfile()-Instanz den neuen Inode über inode_init_owner(), wobei mapped_fsuid()/mapped_fsgid() INVALID_UID/INVALID_GID zurückgeben. Die tmpfile-Datei endet somit mit dem Eigentümer (uid_t)-1.
Jeder andere Erzeugungspfad lehnt dies bereits ab: may_o_create() (O_CREAT) und may_create_dentry() (mkdir, mknod, symlink, link) brechen mit -EOVERFLOW über fsuidgid_has_mapping() ab, genau um zu verhindern, dass ein Objekt erstellt wird, dessen Eigentümer vom Dateisystem nicht dargestellt werden kann. Eine O_TMPFILE-Dateie ist hiervon keine Ausnahme: Sie wird als I_LINKABLE erstellt und kann später durch linkat(2) in den Namespace eingefügt werden; daher muss dieselbe Garantie gelten.
Fügen Sie die fehlende fsuidgid_has_mapping()-Prüfung zu vfs_tmpfile() hinzu. Bei einem nicht-idgemappten Mount sind die fs{u,g}id des Aufrufers immer im Benutzernamespace des Superblocks abgebildet, sodass dies dort keine Wirkung hat und nur auf einen idgemappten Mount wirkt, der den Aufrufer nicht abbildet. Dies gilt für jedes Dateisystem, das FS_ALLOW_IDMAP festlegt und ->tmpfile() implementiert (tmpfs, ext4, btrfs, xfs, f2fs, ...), sowie für overlayfs, dessen tmpfile-Erstellung in der oberen Ebene über backing_tmpfile_open() durch vfs_tmpfile() geleitet wird.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.