Odebrany

CVE-2026-98939

opublikowano: 23.10.2026, 15:17

modyfikacja: 23.10.2026, 15: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ę:

x86/mm: Upuść niepotrzebną kopię strony PMD podczas zwalniania

W przypadku pudełka z oddzielnym procesorem graficznym lockdep zgłasza możliwy zakleszczenie jako
gdy tylko kswapd zmniejszy pulę stron TTM. Bezpośrednią przyczyną jest
Zatwierdzenie x86, które dodało mmap_read_lock() do ochrony strony jądra
kod mungujący.

Ogromny kod vmap utrzymuje tę samą blokadę w przypadku alokacji GFP_KERNEL,
co jest nie-nie, ponieważ odzyskanie może to wytrzymać. Przydział ten jest w a
*wolna* ścieżka do tabeli stron i kończy się na wątpliwych celach[1].
Zasadniczo próbuje uniknąć ustawienia sprzętu Accessed=1 w tabeli stron
wpisy, które są niedostępne dla sprzętu, nie stanowią problemu.

Usuń kopię PMD. Odłącz oryginalną stronę PMD od PUD i wyrównaj
pamięci podręczne średniego poziomu i zwalniaj tabele PTE bezpośrednio z pliku
odłączona strona PMD. Gdy nie ma już przydziału, problem blokowania zniknął.

Mapa/analiza Lockdepa:

OSTRZEŻENIE: wykryto możliwą zależność blokowania cyklicznego
7.3.0-rc3-f6e7b42bf05b+ #183 Skażony: G U
------------------------------------------------------
kswapd0/269 próbuje uzyskać blokadę:
((init_mm).mmap_lock){++++}-{4:4}, pod adresem: zmiana_strony_attr_set_clr+0x29a/0x4a0
ale zadanie już blokuje:
(pool_shrink_rwsem){.+.+}-{4:4}, o: ttm_pool_shrink+0xb2/0x330 [ttm]
Łańcuch istnieje:
(init_mm).mmap_lock --> fs_reclaim --> basen_shrink_rwsem

Cykl zbudowany jest z trzech krawędzi:

1) basen_shrink_rwsem -> (init_mm).mmap_lock

Zmniejszacz TTM przywraca atrybut pamięci podręcznej każdej strony
zwalnia, trzymając basen_shrink_rwsem:

ttm_pool_shrink()
-> ttm_pool_dispose_list()
-> ttm_pool_free_page()
-> set_pages_wb()
-> zmień_stronę_attr_set_clr() [ init_mm mmap blokada odczytu ]

2) fs_reclaim -> Pool_shrink_rwsem

Ten sam skurczacz, wezwany z odzysku.

3) (init_mm).mmap_lock -> fs_reclaim

ioremap() instalująca ogromne mapowanie PUD na istniejącej tabeli PMD:

ioremap_page_range()
-> vmap_range_noflush()
-> vmap_try_huge_pud() [ init_mm mmap blokada odczytu ]
-> pud_free_pmd_page()
-> __get_free_page(GFP_KERNEL) [wchodzi do odzyskania ]

[dhansen: Dużo zmian/przycinania dziennika zmian i połączonych komentarzy z my
wersja poprawki. ]

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

x86/mm: Drop unnecessary PMD page copy when freeing

On a box with a discrete GPU, lockdep reports a possible deadlock as
soon as kswapd shrinks the TTM page pool. The immediate cause is an
x86 commit that added an mmap_read_lock() to kernel page protection
munging code.

The huge vmap code holds the same lock over a GFP_KERNEL allocation,
which is a no-no now that reclaim can take it. That allocation is in a
page table *free* path and ends up being for dubious purposes[1].
Basically, it tries to avoid hardware setting Accessed=1 in page table
entries that are unreachable by the hardware, a non-issue.

Remove the PMD copy. Detach the original PMD page at the PUD, flush
the mid-level caches, and free the PTE tables straight from the
detached PMD page. With no allocation left, the locking issue is gone.

Lockdep splat/analysis:

WARNING: possible circular locking dependency detected
7.3.0-rc3-f6e7b42bf05b+ #183 Tainted: G U
------------------------------------------------------
kswapd0/269 is trying to acquire lock:
((init_mm).mmap_lock){++++}-{4:4}, at: change_page_attr_set_clr+0x29a/0x4a0
but task is already holding lock:
(pool_shrink_rwsem){.+.+}-{4:4}, at: ttm_pool_shrink+0xb2/0x330 [ttm]
Chain exists of:
(init_mm).mmap_lock --> fs_reclaim --> pool_shrink_rwsem

The cycle is built from three edges:

1) pool_shrink_rwsem -> (init_mm).mmap_lock

The TTM shrinker restores the caching attribute of every page it
frees, while holding pool_shrink_rwsem:

ttm_pool_shrink()
-> ttm_pool_dispose_list()
-> ttm_pool_free_page()
-> set_pages_wb()
-> change_page_attr_set_clr() [ init_mm mmap read lock ]

2) fs_reclaim -> pool_shrink_rwsem

The same shrinker, called from reclaim.

3) (init_mm).mmap_lock -> fs_reclaim

ioremap() installing a huge PUD mapping over an existing PMD table:

ioremap_page_range()
-> vmap_range_noflush()
-> vmap_try_huge_pud() [ init_mm mmap read lock ]
-> pud_free_pmd_page()
-> __get_free_page(GFP_KERNEL) [ enters reclaim ]

[ dhansen: Lots of changelog munging/trimming and merged comments from my
version of the fix. ]

>_ 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