CVE-2026-98166: drm/ttm: fix swapped-out resources never leaving their bulk_move range

In the Linux kernel, the following vulnerability has been resolved:

drm/ttm: fix swapped-out resources never leaving their bulkmove range

ttmttswapout() 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 ttmboswapout() infinite LRU walk on swapout failure") moved the bulkmove bookkeeping in ttmboswapoutcb() under "if (!ret)", so the ttmresourcedelbulkmoveunevictable() / ttmresourcemovetolrutail() pair is now skipped on every successful swapout. The equivalent change for the shrinker in commit 1d59f36e95f7 ("drm/ttm: Fix ttmboshrink() 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 bulkmove before the swapout; since then a swapped-out resource stays inside its BO's bulkmove range (and on the manager LRU) although it is unevictable. When it is later freed or the BO leaves the bulkmove (ttmresourcefree(), ttmbosetbulkmove() via amdgpuvmbodel()), ttmresourcedelbulkmove() skips it because of its !ttmresourceunevictable() guard, so a range endpoint in pos->first / pos->last is left pointing at freed memory. The next ttmlrubulkmovetail() or ttmresourceaddbulkmove() on that cursor is a use-after-free, seen as the resv WARN in ttmlrubulkmoveadd(), "listdel corruption" in ttmresourcemovetolrutail() or a NULL dereference in ttmresourcemanagernext() -- 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 ttmttswapout() calls and zero ttmresourcedelbulkmoveunevictable() calls. With this change the removal happens for every swapped-out resource and 12 further cycles were clean.