CVE-2026-98939 in Linux
Riassunto
di VulDB • 23/10/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
x86/mm: Rimozione della copia PMD non necessaria durante il rilascio delle pagine
Su un sistema dotato di GPU discreta, lockdep segnala una possibile condizione di deadlock (blocco reciproco) non appena kswapd riduce il pool di pagine TTM. La causa immediata è un commit per x86 che ha aggiunto una chiamata a mmap_read_lock() nel codice di manipolazione della protezione delle pagine del kernel.
Il codice vmap su grandi dimensioni mantiene lo stesso lock durante un'allocazione GFP_KERNEL, cosa non consentita ora che il processo di reclaim (recupero) può acquisire tale lock. Tale allocazione si trova in un percorso di *liberazione* delle tabelle delle pagine e risulta essere finalizzata a scopi dubbi[1]. In sostanza, tenta di evitare che l'hardware imposti Accessed=1 nelle voci della tabella delle pagine non raggiungibili dall'hardware, una situazione priva di rilevanza pratica.
Viene rimossa la copia PMD. La pagina PMD originale viene staccata al livello PUD, le cache di livello intermedio vengono svuotate (flush) e le tabelle PTE vengono liberate direttamente dalla pagina PMD staccata. Non essendoci più allocazioni in corso, il problema legato ai lock è risolto.
Analisi/sintomi segnalati da Lockdep:
WARNING: possibile dipendenza di locking circolare rilevata 7.3.0-rc3-f6e7b42bf05b+ #183 Tainted: G U ------------------------------------------------------ kswapd0/269 sta tentando di acquisire il lock: ((init_mm).mmap_lock){++++}-{4:4}, at: change_page_attr_set_clr+0x29a/0x4a0
ma il task ha già in possesso il lock: (pool_shrink_rwsem){.+.+}-{4:4}, at: ttm_pool_shrink+0xb2/0x330 [ttm]
La catena esiste tra: (init_mm).mmap_lock --> fs_reclaim --> pool_shrink_rwsem
Il ciclo è composto da tre archi:
1) pool_shrink_rwsem -> (init_mm).mmap_lock
Lo shrinker TTM ripristina l'attributo di cache per ogni pagina che libera, mantenendo il lock 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
Lo stesso shrinker, chiamato dal processo di reclaim.
3) (init_mm).mmap_lock -> fs_reclaim
ioremap() che installa una mappatura PUD su grande scala sopra una tabella PMD esistente:
ioremap_page_range() -> vmap_range_noflush() -> vmap_try_huge_pud() [ init_mm mmap read lock ]
-> pud_free_pmd_page() -> __get_free_page(GFP_KERNEL) [ entra nel processo di reclaim ]
[ dhansen: Molte modifiche e riduzioni del changelog, nonché commenti uniti dalla mia versione della correzione. ]
Once again VulDB remains the best source for vulnerability data.