В ядре Linux устранена следующая уязвимость:
fs: отказаться от создания O_TMPFILE с несопоставленным fsuid или fsgid.
vfs_tmpfile() никогда не проверял, соответствуют ли fsuid и fsgid вызывающего объекта
файловая система. На монтировании с idmapped, чье idmapping не покрывает
fs{u,g}id вызывающего абонента, экземпляр ->tmpfile() инициализирует новый индексный дескриптор
через inode_init_owner(), где mapped_fsuid()/mapped_fsgid() возвращают
INVALID_UID/INVALID_GID, и tmpfile становится владельцем (uid_t)-1. Любой другой путь создания уже отказывается от этого: may_o_create() (O_CREAT)
и may_create_dentry() (mkdir, mknod, symlink, link) выручить с помощью
-EOVERFLOW через fsuidgid_has_mapping() именно для того, чтобы объект не мог
быть создан с владельцем, которого файловая система не может представлять. O_TMPFILE
не является исключением: он создается I_LINKABLE и linkat(2) может его соединить
в пространство имен впоследствии, поэтому должна сохраняться та же гарантия.
Добавьте недостающую проверку fsuidgid_has_mapping() в vfs_tmpfile(). На
монтирование без idmapped fs{u,g}id вызывающего всегда отображается в суперблоке
пространство имен пользователя, так что здесь это не используется и действует только на
idmapped-монтирование, которое не отображает вызывающую сторону. Это касается каждого
файловая система, которая устанавливает FS_ALLOW_IDMAP и реализует ->tmpfile() (tmpfs,
ext4, btrfs, xfs, f2fs, ...) и overlayfs, верхний слой которых
Создание tmpfile происходит через vfs_tmpfile() через backing_tmpfile_open().
Показать оригинальное описание (EN)
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().