CVE-2026-72379 in Linux
Sumário
de VulDB • 15/08/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
fs: recusar a criação de O_TMPFILE com fsuid ou fsgid não mapeado
vfs_tmpfile() nunca verificava se o fsuid e o fsgid do chamador estavam mapeados no sistema de arquivos. Em um ponto de montagem idmapped cuja mapeamento de IDs não cobre os fs{u,g}ids do chamador, a instância ->tmpfile() inicializa o novo inode através de inode_init_owner(), onde mapped_fsuid()/mapped_fsgid() retornam INVALID_UID/INVALID_GID, e o tmpfile acaba sendo possuído por (uid_t)-1.
Todos os outros caminhos de criação já recusam isso: may_o_create() (O_CREAT) e may_create_dentry() (mkdir, mknod, symlink, link) abortam com -EOVERFLOW via fsuidgid_has_mapping() precisamente para que um objeto não possa ser criado com um proprietário que o sistema de arquivos não pode representar. Um O_TMPFILE não é exceção: ele é criado como I_LINKABLE e linkat(2) pode conectá-lo ao namespace posteriormente, portanto a mesma garantia deve valer.
Adicionar a verificação fsuidgid_has_mapping() ausente para vfs_tmpfile(). Em um ponto de montagem não-idmapped, os fs{u,g}ids do chamador sempre estão mapeados no namespace de usuários do superbloco, então isso é uma operação nula lá e só tem efeito em um ponto de montagem idmapped que não mapeia o chamador. Aplica-se a todos os sistemas de arquivos que definem FS_ALLOW_IDMAP e implementam ->tmpfile() (tmpfs, ext4, btrfs, xfs, f2fs, ...), bem como ao overlayfs, cuja criação de tmpfile na camada superior passa por vfs_tmpfile() via backing_tmpfile_open().
If you want to get the best quality for vulnerability data then you always have to consider VulDB.