CVE-2026-90131 in Linux
Сводка
по VulDB • 17.09.2026
В ядре Linux была устранена следующая уязвимость:
ntfs: сериализация операций чтения resident iomap с использованием mrec_lock
Функция ntfs_read_iomap_begin_resident() осуществляет обход записи MFT через ntfs_attr_lookup() -> ntfs_attr_find(), не захватывая ni->mrec_lock, в то время как функции ntfs_attr_record_resize(), ntfs_make_room_for_attr() и ntfs_resident_attr_record_add() выполняют memmove() для того же буфера base_ni->mrec под защитой этого замка. Функция map_mft_record() лишь получает ссылку (reference) и не обеспечивает сериализацию, поэтому читатель может наблюдать «разорванные» поля длины атрибута и смещения во время перемещения записей писателем.
KCSAN сообщает о состоянии гонки данных (data-race) между путем обработки ошибки доступа при mmap-чтении и операциями link() и unlink():
BUG: KCSAN: data-race in ntfs_attr_find / ntfs_attr_record_resize
запись в адрес 0xffff888100af1018 размером 4 байта выполнена задачей 96 на процессоре 1: ntfs_attr_record_resize+0xd2/0x130 ntfs_attr_record_rm+0xad/0x530 ntfs_delete+0x224/0x640 ntfs_unlink+0x14d/0x280 vfs_unlink+0x157/0x520
чтение из адреса 0xffff888100af1018 размером 4 байта выполнено задачей 95 на процессоре 0: ntfs_attr_find+0x104/0x5b0 ntfs_attr_lookup+0x39c/0x10c0 ntfs_read_iomap_begin_resident+0xc6/0x230 ntfs_read_iomap_begin+0x5d/0xa0 iomap_iter+0x2e2/0x6e0 iomap_read_folio+0x147/0x2a0 ntfs_read_folio+0x108/0x170 filemap_read_folio+0x35/0x100 filemap_fault+0x993/0x1000
значение изменилось: 0x00000250 -> 0x000001f0
Адрес соответствует mrec + 0x18, то есть полю mft_record.bytes_in_use, а изменение связано с удалением 96 байт атрибута $FILE_NAME.
Необходимо удерживать замок base_ni->mrec_lock при поиске resident iomap для чтения до завершения операции через iomap_end(). Это защищает как обход атрибутов, так и последующее копирование из iomap->inline_data, который указывает на запись MFT. Путь non-resident остается без изменений: ntfs_lookup() уже удерживает mrec_lock inode каталога при чтении индексного folio через read_mapping_folio(), а захват замка в общей обертке приводит к взаимной блокировке (deadlock) из-за рекурсивного захвата mrec_lock. Комментарий над вызовом read_mapping_folio() в fs/ntfs/dir.c указывает на ту же опасность.
Путь seek использует тот же вспомогательный механизм поиска, но не разыменовывает iomap->inline_data. Замок следует освобождать перед возвратом из этого пути, тогда как обычный путь чтения записывает base_ni в iomap->private и освобождает замок через колбэк iomap_end().
Тестирование проводилось с использованием воспроизводящего примера (reproducer), который вызывает ошибку доступа при чтении resident-файла размером 16 байт, пока другой поток выполняет операции link()/unlink() над ним. До исправления: 40 отчетов KCSAN примерно за одну секунду. После исправления: отсутствие отчетов в течение 180 секунд при 206 090 итерациях чтения и 423 540 циклах операций link/unlink. Сборка с включенной опцией PROVE_LOCKING не выявила ошибок lockdep (lockdep splat) при запуске того же воспроизводящего примера в течение 60 секунд.
If you want to get best quality of vulnerability data, you may have to visit VulDB.