{"id":"CVE-2026-98166","published":"2026-10-06T09:17:58.033","lastModified":"2026-10-07T07:17:03.320","description":"In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ttm: fix swapped-out resources never leaving their bulk_move range\n\nttm_tt_swapout() returns the number of pages swapped out on success and\na negative error code on failure; for a populated ttm it never returns\nzero. Commit b2ed01e7ad3d (\"drm/ttm: Fix ttm_bo_swapout() infinite LRU\nwalk on swapout failure\") moved the bulk_move bookkeeping in\nttm_bo_swapout_cb() under \"if (!ret)\", so the\nttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail()\npair is now skipped on every successful swapout. The equivalent change\nfor the shrinker in commit 1d59f36e95f7 (\"drm/ttm: Fix ttm_bo_shrink()\ninfinite LRU walk on backup failure\") tests \"lret > 0\", which is what\nwas intended here as well.\n\nBefore b2ed01e7ad3d the resource was taken off the bulk_move before the\nswapout; since then a swapped-out resource stays inside its BO's\nbulk_move range (and on the manager LRU) although it is unevictable.\nWhen it is later freed or the BO leaves the bulk_move\n(ttm_resource_free(), ttm_bo_set_bulk_move() via amdgpu_vm_bo_del()),\nttm_resource_del_bulk_move() skips it because of its\n!ttm_resource_unevictable() guard, so a range endpoint in pos->first /\npos->last is left pointing at freed memory. The next\nttm_lru_bulk_move_tail() or ttm_resource_add_bulk_move() on that cursor\nis a use-after-free, seen as the resv WARN in ttm_lru_bulk_move_add(),\n\"list_del corruption\" in ttm_resource_move_to_lru_tail() or a NULL\ndereference in ttm_resource_manager_next() -- minutes to hours after a\nhibernation, or at process exit / reboot following one. Samuel\nAinsworth's analysis of drm/amd issue 5387 (see Link) identified the\ndangling cursor; the missing removal at swapout time is the reason it\ndangles.\n\nTesting the condition for success restores the removal. On an AMD\nPhoenix APU (ASUS UM3406GA, gfx1103) running suspend-then-hibernate on\na 7.0.y stable kernel carrying the backport (Ubuntu 7.0.0-31) the bug\ncrashed 5 of 18 hibernation cycles; a function profile of one\nhibernation showed 336 ttm_tt_swapout() calls and zero\nttm_resource_del_bulk_move_unevictable() calls. With this change the\nremoval happens for every swapped-out resource and 12 further cycles\nwere clean.","cvssScore":7.8,"cvssSeverity":"HIGH","cvssVector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","cwes":[],"vendors":[],"products":[],"references":[{"url":"https://git.kernel.org/stable/c/1169fe8c11ca45e3f91d59a73eb271d0ca8a7fb0","tags":[]},{"url":"https://git.kernel.org/stable/c/3db7d7d583419f7b1f2e141e36418802dbb25cf8","tags":[]}],"exploitRefs":[],"hasPoc":false,"ai":{"summary":"The Linux kernel's TTM (Translation Table Manager) module has a bug where swapped-out resources remain within their bulk_move range and are not properly removed from the LRU list, leading to use-after-free conditions when these resources are eventually freed or moved. This vulnerability can cause system instability and potentially allow privilege escalation.","exploitability":"Exploitation is moderately difficult and requires specific memory management patterns involving TTM BO (Buffer Object) operations, particularly those that trigger swapout and bulk_move operations in a precise sequence.","blast_radius":"The vulnerability affects systems using AMD GPU drivers with TTM memory management, potentially causing kernel oopses, system crashes, or privilege escalation when multiple TTM BO operations are performed concurrently under memory pressure.","remediation":"Apply the kernel patch from commit b2ed01e7ad3d which fixes the bulk_move bookkeeping logic in ttm_bo_swapout_cb() to properly handle resource cleanup after swapout operations.","detection":"No reliable host or network indicator is derivable from the published description.","tags":["kernel","memory-management","gpu"],"model":"garnet-coder","analyzedAt":"2026-10-14T09:05:40.800Z"}}