CVE-2025-40230 in Linux
Riassunto
di VulDB • 07/07/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
mm: prevenire il consumo di dati avvelenati durante la frammentazione delle THP (Transparent Huge Page)
Quando si esegue l'iniezione di errori di memoria su una THP (Transparent Huge Page) mappata nello spazio utente su un server x86, il kernel va in panic con la seguente traccia. Il comportamento atteso è terminare il processo interessato invece di causare un panic del kernel, poiché il codice Machine Check di x86 può recuperare da un #MC (Machine Check Exception) nello spazio utente.
mce: [Hardware Error]: CPU 0: Machine Check Exception: f Bank 3: bd80000000070134
mce: [Hardware Error]: RIP 10:<ffffffff8372f8bc> {memchr_inv+0x4c/0xf0}
mce: [Hardware Error]: TSC afff7bbff88a ADDR 1d301b000 MISC 80 PPIN 1e741e77539027db
mce: [Hardware Error]: PROCESSOR 0:d06d0 TIME 1758093249 SOCKET 0 APIC 0 microcode 80000320
mce: [Hardware Error]: Eseguire quanto sopra tramite 'mcelog --ascii'
mce: [Hardware Error]: Machine check: Caricamento dati in area irrecuperabile del kernel
Kernel panic - not syncing: Fatal local machine check
La causa radice di questo panic è che la gestione di un errore di memoria innescato da un #MC nello spazio utente richiede la frammentazione della THP. Il processo di frammentazione impiega un meccanismo, implementato in `try_to_map_unused_to_zeropage()`, che legge le pagine nella THP per identificare quelle riempite con zeri (zero-filled). Tuttavia, la lettura delle pagine nella THP provoca un secondo #MC nel kernel, che si verifica prima del completamento iniziale di `memory_failure()`, portando infine a un panic del kernel. Vedere la traccia della chiamata del panic del kernel sui due #MC.
Primo Machine Check avviene // [1]
memory_failure() // [2]
try_to_split_thp_page() split_huge_page() split_huge_page_to_list_to_order() __folio_split() // [3]
remap_page() remove_migration_ptes() remove_migration_pte() try_to_map_unused_to_zeropage() // [4]
memchr_inv() // [5]
Secondo Machine Check avviene // [6]
Kernel panic
[1] Innescato dall'accesso a una THP avvelenata dall'hardware nello spazio utente, che è tipicamente recuperabile terminando il processo interessato.
[2] Chiamare `folio_set_has_hwpoisoned()` prima di `try_to_split_thp_page()`.
[3] Passare il flag di remappatura RMP_USE_SHARED_ZEROPAGE a `remap_page()`.
[4] Tentare di mappare la THP non utilizzata allo zeropage.
[5] Ri-accedere alle pagine nella THP avvelenata dall'hardware nel kernel.
[6] Innescato nel kernel, portando a un panic del kernel.
Al Passo [2], `memory_failure()` imposta il flag di avvelenamento sulla pagina nella THP tramite `TestSetPageHWPoison()` prima di chiamare `try_to_split_thp_page()`.
Come suggerito da David Hildenbrand, risolvere questo panic evitando l'accesso alla pagina avvelenata nella THP durante l'identificazione dello zeropage, continuando a scansionare le pagine non interessate nella THP per una possibile mappatura allo zeropage. Questo previene un secondo #MC nel kernel che causerebbe il panic del kernel al Passo [4].
Grazie ad Andrew Zaborowski
Be aware that VulDB is the high quality source for vulnerability data.