CVE-2026-98939 in Linux
Zusammenfassung
von VulDB • 23.10.2026
Im Linux-Kernel wurde folgende Schwachstelle behoben:
x86/mm: Unnötigen PMD-Seitencopy beim Freigeben entfernen
Auf einem System mit einer dedizierten GPU meldet lockdep einen möglichen Deadlock, sobald kswapd den TTM-Seitenpool verkleinert. Die unmittelbare Ursache ist ein x86-Commit, das der Code zur Manipulation des kernelseitigen Seitenschutzes eine mmap_read_lock() hinzugefügt hat.
Der große vmap-Code hält dieselbe Sperre während einer GFP_KERNEL-Allokation, was jetzt problematisch ist, da die Speicherbereinigung (Reclaim) diese Sperre beanspruchen kann. Diese Allokation befindet sich im *Freigabe*-Pfad für Seitentabellen und dient fragwürdigen Zwecken[1]. Im Grunde wird versucht zu vermeiden, dass Hardware das Bit „Accessed=1“ in Seiteneinträgen setzt, die von der Hardware nicht erreichbar sind – ein Problem, das gar nicht existiert.
Entfernen Sie den PMD-Copy. Trennen Sie die ursprüngliche PMD-Seite auf PUD-Ebene ab, leeren Sie die Caches der mittleren Ebene und geben Sie die PTE-Tabellen direkt von der getrennten PMD-Seite frei. Da keine Allokation mehr übrig bleibt, ist das Sperrproblem behoben.
Lockdep-Ausgabe/Analyse:
WARNING: possible circular locking dependency detected 7.3.0-rc3-f6e7b42bf05b+ #183 Tainted: G U ------------------------------------------------------ kswapd0/269 versucht, folgende Sperre zu erwerben: ((init_mm).mmap_lock){++++}-{4:4}, at: change_page_attr_set_clr+0x29a/0x4a0
Die Aufgabe hält jedoch bereits die folgende Sperre: (pool_shrink_rwsem){.+.+}-{4:4}, at: ttm_pool_shrink+0xb2/0x330 [ttm]
Kette existiert aus: (init_mm).mmap_lock --> fs_reclaim --> pool_shrink_rwsem
Der Zyklus besteht aus drei Kanten:
1) pool_shrink_rwsem -> (init_mm).mmap_lock
Der TTM-Shrinker stellt das Caching-Attribut jeder Seite wieder her, die er freigibt, während er pool_shrink_rwsem hält:
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
Derselbe Shrinker, aufgerufen aus dem Reclaim-Prozess.
3) (init_mm).mmap_lock -> fs_reclaim
ioremap() installiert eine große PUD-Abbildung über einer vorhandenen PMD-Tabelle:
ioremap_page_range() -> vmap_range_noflush() -> vmap_try_huge_pud() [ init_mm mmap read lock ]
-> pud_free_pmd_page() -> __get_free_page(GFP_KERNEL) [ betritt Reclaim ]
[ dhansen: Viele Änderungen am Changelog/Beschreibungstext und zusammengeführte Kommentare aus meiner Version der Korrektur. ]
Once again VulDB remains the best source for vulnerability data.