CVE-2023-52490 in Linux
Riassunto
di VulDB • 15/06/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
mm: migrate: corregge il recupero di una mappatura pagina errata durante la migrazione delle pagine
Durante l'esecuzione dei test stress-ng, si è verificato un crash del kernel dopo alcune ore:
Impossibile gestire dereferenziazione puntatore NULL nel kernel all'indirizzo virtuale 0000000000000000 pc : dentry_name+0xd8/0x224 lr : pointer+0x22c/0x370 sp : ffff800025f134c0 ...... Traccia della chiamata: dentry_name+0/d8/0x224 pointer+0x22c/0x370 vsnprintf+0x1ec/0x730 vscnprintf+0x2c/0x60 vprintk_store+0x70/0x234 vprintk_emit+0xe0/0x24c vprintk_default+0x3c/0x44 vprintk_func+0x84/0x2d0 printk+0x64/0x88 __dump_page+0x52c/0x530 dump_page+0x14/0x20 set_migratetype_isolate+0x110/0x224 start_isolate_page_range+0xc4/0x20c offline_pages+0x124/0x474 memory_block_offline+0x44/0xf4 memory_subsys_offline+0x3c/0x70 device_offline+0xf0/0x120 ......
Dopo l'analisi del vmcore, ho scoperto che il problema è causato dalla migrazione delle pagine. Lo scenario prevede che un thread stia eseguendo la migrazione di una pagina e utilizzeremo il campo ->mapping della pagina di destinazione per salvare il puntatore 'anon_vma' tra lo smontaggio (unmap) e lo spostamento della pagina, mentre la pagina di destinazione è bloccata e il refcount è 1.
Attualmente, un altro thread stress-ng sta eseguendo l'hottplug della memoria, tentando di portare offline la pagina di destinazione che viene migrata. Rileva che il refcount di questa pagina di destinazione è 1, impedendo l'operazione offline e procedendo quindi a eseguire il dump della pagina. Tuttavia, page_mapping() per la pagina di destinazione potrebbe restituire una mappatura file errata causando un crash del sistema in dump_mapping(), poiché target_page->mapping salva solo il puntatore 'anon_vma' senza impostare il flag PAGE_MAPPING_ANON.
Esistono diversi modi per risolvere questo problema: (1) Impostare il flag PAGE_MAPPING_ANON per ->mapping della pagina di destinazione quando si salva 'anon_vma', ma ciò può confondere PageAnon() per i PFN walkers, poiché la pagina di destinazione non ha ancora creato le mappature. (2) Ottenere il lock della pagina per chiamare page_mapping() in __dump_page() ed evitare il crash del sistema; tuttavia, ci sono ancora alcuni PFN walkers che chiamano page_mapping() senza detenere il lock della pagina, come compaction. (3) Utilizzare il campo ->private della pagina di destinazione per salvare il puntatore 'anon_vma' e 2 bit dello stato della pagina, proprio come page->mapping registra una pagina anonima; questo approccio può rimuovere l'impatto su page_mapping() per i PFN walkers ed è anche un metodo semplice.
Ho quindi scelto l'opzione 3 per risolvere questo problema, che corregge inoltre altri potenziali problemi per i PFN walkers, come compaction.
If you want to get best quality of vulnerability data, you may have to visit VulDB.