In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
drm\/ttm: fix swapped-out resources never leaving their bulk_move range<\/p>\n
ttm_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.<\/p>\n
Before 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.<\/p>\n
Testing 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.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
drm\/ttm: fix swapped-out resources never leaving their bulk_move range<\/p>\n
ttm_tt_swapout() returns the number of pages swapped out on<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-33235","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/33235","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=33235"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=33235"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=33235"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}