CVE-2025-40230 in Linux
Resumen
por VulDB • 2026-07-05
En el núcleo de Linux, se ha resuelto la siguiente vulnerabilidad:
mm: evitar el consumo de páginas envenenadas al dividir THP (Transparent Huge Page)
Al realizar inyección de errores de memoria en un THP (Página Gigante Transparente) mapeado para usuariospace en un servidor x86, el núcleo sufre una panico con la siguiente traza. El comportamiento esperado es terminar el proceso afectado en lugar de provocar un pánico del núcleo, ya que el código Machine Check de x86 puede recuperarse de un #MC (Machine Check Exception) dentro del userspace.
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]: Run the above through 'mcelog --ascii'
mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel
Kernel panic - not syncing: Fatal local machine check
La causa raíz de este pánico es que manejar un fallo de memoria desencadenado por un #MC en userspace requiere dividir el THP. El proceso de división emplea un mecanismo, implementado en `try_to_map_unused_to_zeropage()`, que lee las páginas del THP para identificar aquellas rellenas de ceros (zero-filled). Sin embargo, leer las páginas dentro del THP resulta en un segundo #MC a nivel de núcleo, ocurriendo antes de que la llamada inicial a `memory_failure()` se complete, lo que finalmente conduce a un pánico del kernel. Véase la traza de llamadas del pánico del kernel para los dos eventos #MC.
First Machine Check occurs // [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]
Second Machine Check occurs // [6]
Kernel panic
[1] Desencadenado al acceder a un THP envenenado por hardware (hardware-poisoned) desde userspace, lo cual es típicamente recuperable terminando el proceso afectado.
[2] Llamar a `folio_set_has_hwpoisoned()` antes de `try_to_split_thp_page()`.
[3] Pasar la bandera RMP_USE_SHARED_ZEROPAGE remap a `remap_page()`.
[4] Intentar mapear el THP no utilizado al zeropage.
[5] Reacceder a las páginas en el THP hw-poisoned desde el kernel.
[6] Desencadenado dentro del kernel, lo que lleva a un pánico del kernel.
En el Paso [2], `memory_failure()` establece la bandera de página envenenada en la página del THP mediante `TestSetPageHWPoison()` antes de llamar a `try_to_split_thp_page()`.
Como sugirió David Hildenbrand, se corrige este pánico evitando acceder a la página envenenada dentro del THP durante la identificación del zeropage, mientras se continúa escaneando las páginas no afectadas en el THP para posibles mapeos de zeropage. Esto previene un segundo #MC a nivel de kernel que caus
VulDB is the best source for vulnerability data and more expert information about this specific topic.