CVE-2026-98166

What it actually does

Use-after-free in TTM bulk-move LRU cursors: successful ttm_tt_swapout() no longer removes the resource from its bulk_move range, leaving pos->first/pos->last pointers dangling after the resource is later freed via ttm_resource_free or ttm_bo_set_bulk_move.

Why it matters to the business

Linux systems using affected DRM/TTM graphics drivers experience crashes minutes to hours after hibernation or during process exit/reboot following hibernation, causing system instability and potential data loss in environments that rely on suspend-to-disk.

How an attack unfolds

An attacker with local access triggers memory pressure or explicit hibernation to cause swapout of TTM resources; the dangling bulk-move cursor is later dereferenced by ttm_lru_bulk_move_tail, ttm_resource_move_to_lru_tail or ttm_resource_manager_next, resulting in list corruption, NULL dereference or WARN, manifesting as a kernel panic.

How to fix it

Apply the upstream fix that restores the ttm_resource_del_bulk_move_unevictable call on every successful swapout (test condition "!ret" changed to success count > 0); update to a kernel containing commit equivalent to the referenced change; reboot after upgrade.

How to confirm the fix worked

Confirm the kernel contains the corrected condition in ttm_bo_swapout_cb; run repeated hibernate-then-resume cycles while monitoring for ttm_resource warnings or panics; verify ttm_resource_del_bulk_move_unevictable is called on every swapout via function tracing.

Typical attack path

1. Obtain local unprivileged access on a vulnerable Linux kernel
2. Induce hibernation or sustained memory pressure to force ttm_tt_swapout on populated TTM objects
3. Trigger subsequent TTM operations (ttm_bo_set_bulk_move, resource free, or LRU walk) that dereference the stale bulk-move cursor
4. Observe kernel panic from list_del corruption, resv WARN, or NULL dereference in TTM LRU code

How to detect it

Search kernel logs and crash dumps for TTM LRU messages including resv WARN, list_del corruption in ttm_resource_move_to_lru_tail, NULL dereference in ttm_resource_manager_next, or absence of ttm_resource_del_bulk_move_unevictable calls during swapout; correlate with hibernation events.

• list_del corruption
• ttm_lru_bulk_move_add
• ttm_resource_move_to_lru_tail
• ttm_resource_manager_next
• resv WARN

What your security team should do

• Prioritize kernel update on all systems that perform hibernation or use AMD/TTM graphics drivers
• Monitor kernel logs for TTM LRU corruption messages until patches are deployed
• Test hibernation workloads in a lab environment before rolling out the fixed kernel
• Disable hibernation where operationally feasible until remediation is complete