Odebrany

CVE-2026-98166

opublikowano: 06.10.2026, 11:17

modyfikacja: 06.10.2026, 11:17

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

drm/ttm: naprawiono wymieniane zasoby, które nigdy nie opuszczały zakresu przenoszenia zbiorczego

ttm_tt_swapout() zwraca liczbę stron zamienionych pomyślnie i
ujemny kod błędu w przypadku awarii; dla zaludnionego ttm nigdy nie powraca
zero. Zatwierdź b2ed01e7ad3d („drm/ttm: Napraw ttm_bo_swapout() nieskończone LRU
chodzić po niepowodzeniu wymiany”) przeniósł księgowość zbiorczą
ttm_bo_swapout_cb() w "if (!ret)", więc
ttm_resource_del_bulk_move_unevictable() / ttm_resource_move_to_lru_tail()
para jest teraz pomijana przy każdej udanej zamianie. Równoważna zmiana
dla zmniejszacza w zatwierdzeniu 1d59f36e95f7 („drm/ttm: Napraw ttm_bo_shrink()
nieskończone przejście LRU w przypadku awarii kopii zapasowej”) testuje „lret > 0”, czyli co
było zamierzone również tutaj.

Przed b2ed01e7ad3d zasób został usunięty z ruchu zbiorczego przed
zamiana; od tego momentu wymieniony zasób pozostaje w swoim BO
zakres Bulk_move (i na menedżerze LRU), chociaż jest to nieuniknione.
Kiedy zostanie później zwolniony lub BO opuści plik zbiorczy_move
(ttm_resource_free(), ttm_bo_set_bulk_move() poprzez amdgpu_vm_bo_del()),
ttm_resource_del_bulk_move() pomija to z powodu
!ttm_resource_unevictable()guard, więc punkt końcowy zakresu w pozycji->pierwszy /
pos->last pozostaje wskazując na zwolnioną pamięć. Następny
ttm_lru_bulk_move_tail() lub ttm_resource_add_bulk_move() na tym kursorze
jest wolnym od użycia, postrzeganym jako resv WARN w ttm_lru_bulk_move_add(),
„korupcja list_del” w ttm_resource_move_to_lru_tail() lub NULL
dereferencja w ttm_resource_manager_next() -- minuty do godzin po a
hibernacja lub przy wyjściu/restartie procesu po hibernacji. Samuela
Analiza Ainswortha dotycząca problemu drm/amd 5387 (patrz link) zidentyfikowała
zwisający kursor; przyczyną jest brakujące usunięcie w momencie wymiany
zwisa.

Sprawdzenie warunku powodzenia przywraca usunięcie. Na AMD
APU Phoenix (ASUS UM3406GA, gfx1103) działa w trybie wstrzymania, a następnie hibernacji
stabilne jądro 7.0.y z backportem (Ubuntu 7.0.0-31) błąd
zawiesił 5 z 18 cykli hibernacji; profil funkcji jednego
hibernacja pokazała 336 wywołań ttm_tt_swapout() i zero
wywołania ttm_resource_del_bulk_move_unevictable(). Dzięki tej zmianie
usuwanie następuje dla każdego wymienianego zasobu i przez 12 kolejnych cykli
były czyste.

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.

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve