https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 14:45:05 +0000 https://vulnerability.circl.lu/vuln/cve-2026-52965 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure</p> <p>When ttm_tt_swapout() fails, the current code calls ttm_resource_add_bulk_move() followed by ttm_resource_move_to_lru_tail() to restore the resource&#39;s bulk_move membership.</p> <p>However, ttm_resource_move_to_lru_tail() places the resource at the tail of the LRU list which, relative to the walk cursor&#39;s hitch node (placed immediately after the resource when it was yielded), puts the resource *in front of the* the hitch. The next list_for_each_entry_continue() from the hitch finds the same resource again, causing an infinite loop.</p> <p>Fix by deferring del_bulk_move to the success path only.</p> <p>On the success path, TTM_TT_FLAG_SWAPPED has just been set by ttm_tt_swapout() but the resource is still tracked in the bulk_move range, so ttm_resource_del_bulk_move()&#39;s !ttm_resource_unevictable() guard would incorrectly skip the removal. Introduce ttm_resource_del_bulk_move_unevictable() which bypasses that guard.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure</p> <p>When ttm_tt_swapout() fails, the current code calls ttm_resource_add_bulk_move() followed by ttm_resource_move_to_lru_tail() to restore the resource&#39;s bulk_move membership.</p> <p>However, ttm_resource_move_to_lru_tail() places the resource at the tail of the LRU list which, relative to the walk cursor&#39;s hitch node (placed immediately after the resource when it was yielded), puts the resource *in front of the* the hitch. The next list_for_each_entry_continue() from the hitch finds the same resource again, causing an infinite loop.</p> <p>Fix by deferring del_bulk_move to the success path only.</p> <p>On the success path, TTM_TT_FLAG_SWAPPED has just been set by ttm_tt_swapout() but the resource is still tracked in the bulk_move range, so ttm_resource_del_bulk_move()&#39;s !ttm_resource_unevictable() guard would incorrectly skip the removal. Introduce ttm_resource_del_bulk_move_unevictable() which bypasses that guard.</p> https://vulnerability.circl.lu/vuln/cve-2026-52965