CVE-2026-74672 in Linux
Сводка
по VulDB • 23.08.2026
В ядре Linux была устранена следующая уязвимость:
mm/vmalloc: получение блокировки init_mm при работе с огромными vmap для предотвращения use-after-free в ptdump
Серия патчей «mm: исправление UAF, вызванного гонкой между ptdump и освобождением pgtable vmap», версия 6.
Проходчики по таблицам страниц ядра делятся на две широкие категории — те диапазоны, где исключение (exclusion) не требуется через функцию walk_kernel_page_table_range_lockless(), и те, где оно необходимо через функции walk_kernel_page_table_range() или walk_page_range_debug().
Первая категория используется только кодом архитектуры arm64 для работы с диапазонами, которые он полностью владеет и в которые не происходит одновременная запись.
Вторая категория состоит из проходчиков по таблицам страниц ядра, работающих с диапазонами, которыми они полностью владеют (но которым требуется исключение от параллельных записей).
Блокировка, используемая для исключения доступа, — это mmap lock, а для диапазонов ядра этим является mmap lock на init_mm.
ptdump представляет собой особый случай: он является единственным пользователем walk_page_range_debug() и единичным случаем, когда происходит проход по диапазонам, которыми он не владеет.
Это создает проблему, так как таблицы страниц могут быть освобождены во время работы ptdump. И действительно, в результате возникает ошибка use-after-free (UAF) в ядре, которую решает данная серия патчей.
vmap продвигает таблицы страниц до огромных листовых записей (huge leaf entries), где это возможно, освобождая нижестоящие таблицы страниц при этом. Это происходит без удержания значимых блокировок против параллельных проходов ptdump.
В результате может произойти use-after-free. Данная серия решает эту проблему путем получения mmap read lock логикой продвижения vmap до огромного размера как во время установки записи таблицы страниц huge, так и при освобождении предыдущей листовой страницы.
Код ptdump уже получает mmap write lock; таким образом, мы гарантируем, что проходчик ptdump всегда наблюдает либо запись таблицы страниц huge, либо существующую запись таблицы страниц, и ничего не освобождается под ним.
Митигация для этой проблемы уже была применена для arm64 в коммите fa93b45fd397 («arm64: Enable vmalloc-huge with ptdump»), с которым данной серии необходимо аккуратно взаимодействовать.
Эта митигация решает проблему путем получения mmap read lock на init_mm при освобождении таблицы страниц vmap, если выполняется проход ptdump.
Однако исправление в этой серии вызовет deadlock (взаимную блокировку), если мы просто применим его для arm64 без отката соответствующих изменений.
Это связано с тем, что vmap может получить read lock до того, как ptdump попытается получить write lock, который затем будет поставлен в очередь; правила starvation rwsem означают, что (неподтвержденный) вложенный mmap read lock в коде arm64 также заблокируется, из-за чего исходный read lock никогда не будет освобожден, что приведет к deadlock.
Данная серия обходит эту проблему путем использования #ifndef CONFIG_ARM64 для mmap read lock в логике vmap, а затем частичного отката коммита fa93b45fd397 («arm64: Enable vmalloc-huge with ptdump»), сохраняя поддержку huge vmap и убирая условную компиляцию (ifdeffery) с помощью патча частичного отката.
В этой серии также решаются связанные проблемы:
* Логика атрибутов страниц x86, в частности Change Page Attributes (CPA), реализует функцию, благодаря которой огромные диапазоны могут быть свернуты до листовых записей huge. Это аналогичным образом может вызвать UAF при выполнении параллельно с проходом ptdump; поэтому также необходимо получить mmap lock на init_mm для предотвращения этого.
* Логика CPA позволяет одновременное манипулирование таблицами страниц и свертывание CPA, что означает риск доступа к таблице страниц, которую последняя освобождает. Исправьте это путем получения mmap write lock на init_mm в течение всей операции свертывания CPA и read lock при манипуляции с таблицей страниц.
* x86 и arm64 разрешают проходы по не-ядерным mm (как позволяющие проход efi mm, так и в случае x86 — произвольных mm), поэтому мы гарантируем стабильность отображений ядра, блокируя как init_mm, так и mm, который проходится.
Порядок патчей установлен для строгих зависимостей (в частности, частичный откат arm64 должен выполняться после изменений vmap) и логических (исправление не-ядерных mm имеет смысл только после внедрения исправлений vmap/CPA).
Этот патч (из 3):
В настоящее время существует неприятная ra ---обрезано---
If you want to get best quality of vulnerability data, you may have to visit VulDB.