В ядре Linux устранена следующая уязвимость:
fs/ntfs3: привязанный индекс copy_lcns dp->page_lcns[] в проходе анализа
На этапе анализа log_replay() после того, как find_dp() возвращает
действительный DIR_PAGE_ENTRY для кортежа (target_attr, target_vcn),
блок copy_lcns проходит lrh->lcns_follow дальнейшие записи:
t16 = le16_to_cpu(lrh->lcns_follow);
для (я = 0; я < t16; я++) {
size_t j = (size_t)(le64_to_cpu(lrh->target_vcn) -
le64_to_cpu(dp->vcn));
dp->page_lcns[j + i] = lrh->page_lcns[i];
}
find_dp() только проверяет, попадает ли target_vcn в пределы
[dp->vcn, dp->vcn + dp->lcns_follow), т.е. что ПЕРВЫЙ
кластер закрыт. Прогулка по дальнейшим записям
не ограничен dp->lcns_follow. Для уродливого ЛРХ
где target_vcn = dp->vcn + dp->lcns_follow - 1 и
lrh->lcns_follow > 1, записи i > 0 переполняют dp
выделенный массив page_lcns[].
Добавьте недостающий охранник j + lrh->lcns_follow <= dp->lcns_follow. Воспроизводится под UML+KASAN на основной ветке 8d90b09e6741 как
запись за пределами поля размера 8 из log_replay+0x68d4 вкл.
путь монтирования. Это отличается от патча Павитры Джа от 2 мая 2026 г.
(«fs/ntfs3: проверьте lcns_follow при преобразовании log_replay»,
<20260502154252.164586-1-jhapavitra98@gmail.com>), который
обращается к отдельному преобразованию таблицы грязных страниц версии 0
вызов memmove(&dp->vcn, ...) пути.
Два исправления дополнительный; оба должны приземлиться. [almaz.alexandrovich@paragon-software.com: отформатировал изменения в clang, фиксированные конфликты]
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: bound copy_lcns dp->page_lcns[] index in analysis pass In log_replay()'s analysis pass, after find_dp() returns a valid DIR_PAGE_ENTRY for the (target_attr, target_vcn) tuple, the copy_lcns block walks lrh->lcns_follow further entries: t16 = le16_to_cpu(lrh->lcns_follow); for (i = 0; i < t16; i++) { size_t j = (size_t)(le64_to_cpu(lrh->target_vcn) - le64_to_cpu(dp->vcn)); dp->page_lcns[j + i] = lrh->page_lcns[i]; } find_dp() only validates that target_vcn falls within [dp->vcn, dp->vcn + dp->lcns_follow), i.e., that the FIRST cluster is covered. The walk through the further entries is not bounded against dp->lcns_follow. For a malformed LRH where target_vcn = dp->vcn + dp->lcns_follow - 1 and lrh->lcns_follow > 1, the i > 0 writes overflow the dp's allocated page_lcns[] array. Add the missing j + lrh->lcns_follow <= dp->lcns_follow guard. Reproduced under UML+KASAN on mainline 8d90b09e6741 as a slab-out-of-bounds write of size 8 from log_replay+0x68d4 on the mount path. This is distinct from Pavitra Jha's 2026-05-02 patch ("fs/ntfs3: validate lcns_follow in log_replay conversion", <20260502154252.164586-1-jhapavitra98@gmail.com>) which addresses the separate version-0 dirty-page-table conversion path's memmove(&dp->vcn, ...) call. The two fixes are complementary; both should land. [almaz.alexandrovich@paragon-software.com: clang-formatted the changes, fixed conflicts]
Характеристики атаки
Последствия
Строка CVSS v3.1