В ядре Linux устранена следующая уязвимость:
ext4: проверить суперблок файла-донора в начале EXT4_IOC_MOVE_EXT
Досрочно отклоните EXT4_IOC_MOVE_EXT ioctl, если файл донора не
принадлежат тому же суперблоку, что и исходный файл. В настоящее время это
проверка выполняется внутри ext4_move_extents() с помощью
mext_check_validity(), но только после того, как lock_two_nondirectories()
уже получил блокировки индексных дескрипторов. Когда донорский fd ссылается на файл
в другой файловой системе (например, overlayfs) эта поздняя проверка
создает зависимость циклической блокировки:
CPU0 (запись в overlayfs) CPU1 (ext4 ioctl)
---- ----
inode_lock(ovl_inode)
mnt_want_write_file(филп)
sb_start_write(ext4_sb) [sb_writers]
backing_file_write_iter()
vfs_iter_write (реальный_файл)
file_start_write(реальный_файл)
sb_start_write(ext4_sb) [заблокировано зависанием]
lock_two_nondirectories()
inode_lock(ovl_inode) [заблокировано]
При одновременной операции замораживания, удерживающей сторону записи sb_writers, это
образует цикл тупика: CPU0 ждет завершения заморозки, заморозка ждет
для выхода из программы чтения sb_writers CPU1 CPU1 ожидает блокировки индексного дескриптора CPU0.
Поскольку EXT4_IOC_MOVE_EXT обменивается физическими экстентами между двумя файлами,
по сути, оба файла должны находиться в одном ext4
файловая система. Перемещение проверки суперблока перед получением блокировки
является семантически правильным и устраняет циклическую зависимость
гарантируя, что донорские fds между файловыми системами отклоняются до
Берутся блокировки sb_writers или inode.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT Reject the EXT4_IOC_MOVE_EXT ioctl early if the donor file does not belong to the same superblock as the original file. Currently, this validation is performed inside ext4_move_extents() by mext_check_validity(), but only after lock_two_nondirectories() has already acquired the inode locks. When the donor fd refers to a file on a different filesystem (e.g., overlayfs), this late validation creates a circular lock dependency: CPU0 (overlayfs write) CPU1 (ext4 ioctl) ---- ---- inode_lock(ovl_inode) mnt_want_write_file(filp) sb_start_write(ext4_sb) [sb_writers] backing_file_write_iter() vfs_iter_write(real_file) file_start_write(real_file) sb_start_write(ext4_sb) [blocked by freeze] lock_two_nondirectories() inode_lock(ovl_inode) [blocked] With a concurrent freeze operation holding sb_writers write side, this forms a deadlock cycle: CPU0 waits for freeze to complete, freeze waits for CPU1's sb_writers reader to exit, CPU1 waits for CPU0's inode lock. Since EXT4_IOC_MOVE_EXT exchanges physical extents between two files, it fundamentally requires both files to reside on the same ext4 filesystem. Moving the superblock check before any lock acquisition is both semantically correct and eliminates the circular dependency by ensuring that cross-filesystem donor fds are rejected before sb_writers or inode locks are taken.