CVE-2026-98166 in Linux
Сводка
по VulDB • 06.10.2026
В ядре Linux была устранена следующая уязвимость:
drm/ttm: исправлена проблема, при которой выгруженные (swapped-out) ресурсы никогда не покидали свой диапазон bulk_move.
Функция ttm_tt_swapout() возвращает количество успешно выгруженных страниц в случае успеха и отрицательный код ошибки при сбое; для заполненного объекта ttm она никогда не возвращает ноль. Коммит b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") переместил ведение учета bulk_move в функции ttm_bo_swapout_cb() под условие "if (!ret)", из-за чего пара вызовов ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail() теперь пропускается при каждом успешном выгружении. Аналогичное изменение для shrinker в коммите 1d59f36e95f7 ("drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure") проверяет условие "lret > 0", что и предполагалось изначально.
До коммита b2ed01e7ad3d ресурс удалялся из bulk_move до операции выгруживания; с тех пор выгруженный ресурс остается внутри диапазона bulk_move своего BO (и в LRU менеджера), хотя он является unevictable. Когда он впоследствии освобождается или BO покидает диапазон bulk_move (ttm_resource_free(), ttm_bo_set_bulk_move() через amdgpu_vm_bo_del()), функция ttm_resource_del_bulk_move() пропускает его из-за проверки !ttm_resource_unevictable(), в результате чего конечная точка диапазона в pos->first / pos->last указывает на освобожденную память. Следующий вызов ttm_lru_bulk_move_tail() или ttm_resource_add_bulk_move() для этого курсора представляет собой use-after-free, что проявляется как WARN по resv в ttm_lru_bulk_move_add(), "list_del corruption" (повреждение списка) в ttm_resource_move_to_lru_tail() или разыменование NULL-указателя в ttm_resource_manager_next() — через минуты или часы после гибернации, либо при завершении процесса/перезагрузке после нее. Анализ Samuel Ainsworth проблемы drm/amd issue 5387 (см. ссылку) выявил повисший курсор; отсутствие удаления во время выгруживания является причиной его "повисания".
Проверка условия успеха восстанавливает корректное удаление. На AMD Phoenix APU (ASUS UM3406GA, gfx1103), работающей в режиме suspend-then-hibernate на стабильном ядре 7.0.y с обратным портированием (Ubuntu 7.0.0-31), ошибка приводила к краху 5 из 18 циклов гибернации; профилирование функции одного цикла гибернации показало 36 вызовов ttm_tt_swapout() и ноль вызовов ttm_resource_del_bulk_move_unevictable(). С данным исправлением удаление происходит для каждого выгруженного ресурса, и следующие 12 циклов прошли без сбоев.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.