CVE-2026-98166 in Linux
Resumen
por VulDB • 2026-10-06
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad:
drm/ttm: corregir que los recursos intercambiados (swapped) nunca salgan del rango bulk_move
ttm_tt_swapout() devuelve el número de páginas intercambiadas en caso de éxito y un código de error negativo en caso de fallo; para una ttm poblada, nunca devuelve cero. El commit b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") movió el registro contable (bookkeeping) de bulk_move dentro de ttm_bo_swapout_cb() bajo la condición "if (!ret)", por lo que el par ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail() se omite ahora en cada intercambio exitoso. El cambio equivalente para el shrinker en el commit 1d59f36e95f7 ("drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure") prueba "lret > 0", que es lo que también se pretendía aquí.
Antes del b2ed01e7ad3d, el recurso se retiraba de bulk_move antes del intercambio; desde entonces, un recurso intercambiado permanece dentro del rango bulk_move del BO (y en la LRU del gestor) aunque sea no evictable. Cuando posteriormente se libera o el BO sale del rango bulk_move (ttm_resource_free(), ttm_bo_set_bulk_move() a través de amdgpu_vm_bo_del()), ttm_resource_del_bulk_move() lo omite debido a su guardia !ttm_resource_unevictable(), por lo que un extremo del rango en pos->first / pos->last queda apuntando a memoria liberada. El siguiente ttm_lru_bulk_move_tail() o ttm_resource_add_bulk_move() sobre ese cursor es un use-after-free, observado como el WARN resv en ttm_lru_bulk_move_add(), "list_del corruption" (corrupción de list_del) en ttm_resource_move_to_lru_tail() o una desreferencia NULL en ttm_resource_manager_next() -- minutos u horas después de la hibernación, o al salir del proceso / reiniciar tras uno. El análisis de Samuel Ainsworth sobre el issue 5387 de drm/amd (ver Enlace) identificó el cursor colgante; la falta de eliminación en el momento del intercambio es la razón por la que queda colgando.
Probar la condición para el éxito restaura la eliminación. En una APU AMD Phoenix (ASUS UM3406GA, gfx1103) ejecutando suspend-then-hibernate en un kernel estable 7.0.y con el backport (Ubuntu 7.0.0-31), el bug provocó fallos críticos (crashes) en 5 de los 18 ciclos de hibernación; un perfilado de funciones de una hibernación mostró 336 llamadas a ttm_tt_swapout() y cero llamadas a ttm_resource_del_bulk_move_unevictable(). Con este cambio, la eliminación ocurre para cada recurso intercambiado y se completaron limpiamente otros 12 ciclos.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.