Description

In the Linux kernel, the following vulnerability has been resolved: drm/ttm: fix swapped-out resources never leaving their bulk_move range ttm_tt_swapout() returns the number of pages swapped out on success and a negative error code on failure; for a populated ttm it never returns zero. Commit b2ed01e7ad3d ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") moved the bulk_move bookkeeping in ttm_bo_swapout_cb() under "if (!ret)", so the ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail() pair is now skipped on every successful swapout. The equivalent change for the shrinker in commit 1d59f36e95f7 ("drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure") tests "lret > 0", which is what was intended here as well. Before b2ed01e7ad3d the resource was taken off the bulk_move before the swapout; since then a swapped-out resource stays inside its BO's bulk_move range (and on the manager LRU) although it is unevictable. When it is later freed or the BO leaves the bulk_move (ttm_resource_free(), ttm_bo_set_bulk_move() via amdgpu_vm_bo_del()), ttm_resource_del_bulk_move() skips it because of its !ttm_resource_unevictable() guard, so a range endpoint in pos->first / pos->last is left pointing at freed memory. The next ttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move() on that cursor is a use-after-free, seen as the resv WARN in ttm_lru_bulk_move_add(), "list_del corruption" in ttm_resource_move_to_lru_tail() or a NULL dereference in ttm_resource_manager_next() -- minutes to hours after a hibernation, or at process exit / reboot following one. Samuel Ainsworth's analysis of drm/amd issue 5387 (see Link) identified the dangling cursor; the missing removal at swapout time is the reason it dangles. Testing the condition for success restores the removal. On an AMD Phoenix APU (ASUS UM3406GA, gfx1103) running suspend-then-hibernate on a 7.0.y stable kernel carrying the backport (Ubuntu 7.0.0-31) the bug crashed 5 of 18 hibernation cycles; a function profile of one hibernation showed 336 ttm_tt_swapout() calls and zero ttm_resource_del_bulk_move_unevictable() calls. With this change the removal happens for every swapped-out resource and 12 further cycles were clean.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.8",
  "pubDate": "2026-10-06T09:17:58.033Z",
  "pubdate": "2026-10-06T09:17:58.033Z",
  "executiveSummary": "A use-after-free (UAF) vulnerability exists in the Linux kernel's Translation Table Manager (TTM) subsystem, specifically within the bulk_move memory management logic.\nThe issue arises from improper tracking of swapped-out resources, where resources remain incorrectly associated with a bulk_move range after they have been marked as unevictable.\nThis leads to the corruption of list pointers and the persistence of dangling cursors (pos->first/pos->last) referencing memory that has already been deallocated.\nThe vulnerability affects kernel versions where commit b2ed01e7ad3d was applied without the corrective check for successful swapout operations.\nExploitation is triggered during memory pressure events, hibernation, or process termination, leading to kernel instability, crashes, or potential code execution scenarios due to pointer corruption.\nAttackers capable of triggering heavy memory pressure or hibernation/resumption cycles can induce the memory corruption, though the path is primarily triggered through standard kernel resource management workflows.",
  "technicalDetails": "The root cause is a logic error in ttm_bo_swapout_cb(), introduced by a previous commit intended to fix infinite LRU walks. The fix incorrectly scoped the removal of resources from the bulk_move range to a condition that fails to trigger on successful swapouts.\nWhen a resource is swapped out, it should be removed from the bulk_move range and the associated LRU lists to reflect its unevictable status. Due to the faulty conditional check, the resource remains inside the BO's bulk_move range and the manager LRU.\nBecause the resource is not properly removed, subsequent calls to ttm_resource_free() or ttm_bo_set_bulk_move() (triggered via amdgpu_vm_bo_del()) encounter a resource that is incorrectly identified as still being part of a bulk_move chain. The guard ttm_resource_unevictable() causes the cleanup function ttm_resource_del_bulk_move() to skip the resource entirely.\nThis behavior leaves the bulk_move cursor (pos->first / pos->last) pointing to the memory of the already freed resource. This creates a dangling pointer condition.\nWhen the TTM subsystem later attempts to perform operations like ttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move(), it dereferences these corrupted, dangling pointers. This results in 'list_del corruption', kernel panics, or NULL pointer dereferences.\nThe attack flow follows a predictable pattern: 1) The system enters a memory pressure state or hibernation; 2) ttm_tt_swapout() executes, successfully swapping pages but failing to decouple the resource from the bulk_move structure; 3) The resource is freed, leaving the bulk_move list in a corrupted state; 4) A subsequent kernel operation attempts to traverse the corrupted bulk_move list, leading to a kernel crash (often identified by a resv WARN in ttm_lru_bulk_move_add()).\nThis vulnerability is particularly dangerous because the window between the initial corruption and the eventual crash can be significant, ranging from minutes to hours depending on the system's usage patterns, complicating forensic analysis."
}