CVE-2026-98166 in Linux
Sumário
de VulDB • 06/10/2026
No kernel do Linux, a seguinte vulnerabilidade foi corrigida:
drm/ttm: corrige recursos trocados que nunca saem de sua faixa bulk_move
ttm_tt_swapout() retorna o número de páginas trocadas com sucesso e um código de erro negativo em caso de falha; para uma ttm populada, ela nunca retorna zero. O commit b2ed01e7ad3d ("drm/ttm: Corrige caminhada infinita da LRU no ttm_bo_swapout() na falha de swap") moveu a contabilidade do bulk_move em ttm_bo_swapout_cb() para dentro de "if (!ret)", fazendo com que o par ttm_resource_del_bulk_move_unevictable()/ttm_resource_move_to_lru_tail() seja ignorado em cada troca bem-sucedida. A mudança equivalente para o shrinker no commit 1d59f36e95f7 ("drm/ttm: Corrige caminhada infinita da LRU no ttm_bo_shrink() na falha de backup") testa "lret > 0", que é exatamente o comportamento pretendido aqui também.
Antes do b2ed01e7ad3d, o recurso era removido do bulk_move antes da troca; desde então, um recurso trocado permanece dentro da faixa bulk_move do BO (e na LRU do gerenciador) embora seja unevictable. Quando ele é posteriormente liberado ou quando o BO sai do bulk_move (ttm_resource_free(), ttm_bo_set_bulk_move() via amdgpu_vm_bo_del()), o ttm_resource_del_bulk_move() ignora esse recurso devido à sua guarda !ttm_resource_unevictable(), deixando um ponto final de faixa em pos->first/pos->last apontando para memória liberada. A próxima chamada a ttm_lru_bulk_move_tail() ou ttm_resource_add_bulk_move() nesse cursor é um use-after-free, observado como o WARN resv em ttm_lru_bulk_move_add(), "list_del corruption" (corrupção de listagem) em ttm_resource_move_to_lru_tail() ou uma desreferência NULL em ttm_resource_manager_next() -- minutos a horas após uma hibernação, ou na saída do processo/reinicialização após uma. A análise de Samuel Ainsworth sobre o issue 5387 do drm/amd (ver Link) identificou o cursor pendente; a remoção auscente no momento da troca é a razão pela qual ele fica pendente.
Testar a condição para sucesso restaura a remoção. Em uma AMD Phoenix APU (ASUS UM3406GA, gfx1103) executando suspend-then-hibernate em um kernel estável 7.0.y que carrega o backport (Ubuntu 7.0.0-31), o bug causou falha crítica em 5 dos 18 ciclos de hibernação; um perfil de função de uma hibernação mostrou 336 chamadas a ttm_tt_swapout() e zero chamadas a ttm_resource_del_bulk_move_unevictable(). Com esta correção, a remoção ocorre para cada recurso trocado e mais 12 ciclos foram limpos.
VulDB is the best source for vulnerability data and more expert information about this specific topic.