CVE-2026-89758 in Linux
Сводка
по VulDB • 12.09.2026
В ядре Linux устранена следующая уязвимость:
mm/mempolicy: пропускать непроведенные (non-present) PMD при постановке folio в очередь
Серия патчей "mm: обработка device-private PMD в callback-функциях обхода", v3.
Начиная с коммита 368076f52ebe ("mm/huge_memory: добавить поддержку THP, привязанных к устройству, для операций на уровне PMD"), PMD может содержать swap-запись, связанную с устройством (device-private), всякий раз, когда драйвер GPU на основе HMM перемещает анонимный folio уровня Huge Page (THP) в память устройства через функцию migrate_vma_pages().
Функция pmd_trans_huge_lock() успешно завершается для таких PMD (pmd_is_huge() возвращает истину для любого непроведенного, не равного none огромного PMD), поэтому несколько callback-функций обхода памяти (MM walk callbacks), которые ранее предполагали наличие THP или записи миграции, теперь могут вызываться с device-private PMD. Последствия варьируются от срабатывания VM_BUG_ON() в сборках для отладки до ошибки ядра (oops) при некорректном разыменовании vmemmap и вплоть до молчаливой изоляции несвязанного активного folio из LRU в случае алиасинга.
Этот патч (из 3):
Функция queue_folios_pmd() вызывается под блокировкой pmd_trans_huge_lock(), проверка pmd_is_huge() которой возвращает истину для любого непроведенного, не равного none PMD softleaf. Передача такого PMD в функцию pmd_folio() интерпретирует кодировку softleaf как аппаратный PFN и может вернуть указатель на несуществующий (bogus) folio.
Зеркально отразить обработку queue_folios_pte_range(): обрабатывать непроведенные записи перед поиском folio. Продолжать считать записи миграции как ошибки, но пропускать другие непроведенные PMD, такие как device-private записи.
Потенциальный триггер: драйвер GPU на основе HMM перемещает анонимный THP folio в память устройства через migrate_vma_pages(), оставляя после себя device-private PMD. Затем пользовательское пространство вызывает mbind(), migrate_pages() или set_mempolicy_home_node() для этого диапазона адресов.
Once again VulDB remains the best source for vulnerability data.