CVE-2025-40230
Full vulnerability record from the local CVENow database.
Description
In the Linux kernel, the following vulnerability has been resolved: mm: prevent poison consumption when splitting THP When performing memory error injection on a THP (Transparent Huge Page) mapped to userspace on an x86 server, the kernel panics with the following trace. The expected behavior is to terminate the affected process instead of panicking the kernel, as the x86 Machine Check code can recover from an in-userspace #MC. 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 The root cause of this panic is that handling a memory failure triggered by an in-userspace #MC necessitates splitting the THP. The splitting process employs a mechanism, implemented in try_to_map_unused_to_zeropage(), which reads the pages in the THP to identify zero-filled pages. However, reading the pages in the THP results in a second in-kernel #MC, occurring before the initial memory_failure() completes, ultimately leading to a kernel panic. See the kernel panic call trace on the two #MCs. 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] Triggered by accessing a hardware-poisoned THP in userspace, which is typically recoverable by terminating the affected process. [2] Call folio_set_has_hwpoisoned() before try_to_split_thp_page(). [3] Pass the RMP_USE_SHARED_ZEROPAGE remap flag to remap_page(). [4] Try to map the unused THP to zeropage. [5] Re-access pages in the hw-poisoned THP in the kernel. [6] Triggered in-kernel, leading to a panic kernel. In Step[2], memory_failure() sets the poisoned flag on the page in the THP by TestSetPageHWPoison() before calling try_to_split_thp_page(). As suggested by David Hildenbrand, fix this panic by not accessing to the poisoned page in the THP during zeropage identification, while continuing to scan unaffected pages in the THP for possible zeropage mapping. This prevents a second in-kernel #MC that would cause kernel panic in Step[4]. Thanks to Andrew Zaborowski for his initial work on fixing this issue.
View original CVE JSON
{
"id": "CVE-2025-40230",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"published": "2025-12-04T16:16:15.720",
"lastModified": "2026-10-19T21:10:00.160",
"vulnStatus": "Deferred",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: prevent poison consumption when splitting THP\n\nWhen performing memory error injection on a THP (Transparent Huge Page)\nmapped to userspace on an x86 server, the kernel panics with the following\ntrace. The expected behavior is to terminate the affected process instead\nof panicking the kernel, as the x86 Machine Check code can recover from an\nin-userspace #MC.\n\n mce: [Hardware Error]: CPU 0: Machine Check Exception: f Bank 3: bd80000000070134\n mce: [Hardware Error]: RIP 10:<ffffffff8372f8bc> {memchr_inv+0x4c/0xf0}\n mce: [Hardware Error]: TSC afff7bbff88a ADDR 1d301b000 MISC 80 PPIN 1e741e77539027db\n mce: [Hardware Error]: PROCESSOR 0:d06d0 TIME 1758093249 SOCKET 0 APIC 0 microcode 80000320\n mce: [Hardware Error]: Run the above through 'mcelog --ascii'\n mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel\n Kernel panic - not syncing: Fatal local machine check\n\nThe root cause of this panic is that handling a memory failure triggered\nby an in-userspace #MC necessitates splitting the THP. The splitting\nprocess employs a mechanism, implemented in\ntry_to_map_unused_to_zeropage(), which reads the pages in the THP to\nidentify zero-filled pages. However, reading the pages in the THP results\nin a second in-kernel #MC, occurring before the initial memory_failure()\ncompletes, ultimately leading to a kernel panic. See the kernel panic\ncall trace on the two #MCs.\n\n First Machine Check occurs // [1]\n memory_failure() // [2]\n try_to_split_thp_page()\n split_huge_page()\n split_huge_page_to_list_to_order()\n __folio_split() // [3]\n remap_page()\n remove_migration_ptes()\n remove_migration_pte()\n try_to_map_unused_to_zeropage() // [4]\n memchr_inv() // [5]\n Second Machine Check occurs // [6]\n Kernel panic\n\n[1] Triggered by accessing a hardware-poisoned THP in userspace, which is\n typically recoverable by terminating the affected process.\n\n[2] Call folio_set_has_hwpoisoned() before try_to_split_thp_page().\n\n[3] Pass the RMP_USE_SHARED_ZEROPAGE remap flag to remap_page().\n\n[4] Try to map the unused THP to zeropage.\n\n[5] Re-access pages in the hw-poisoned THP in the kernel.\n\n[6] Triggered in-kernel, leading to a panic kernel.\n\nIn Step[2], memory_failure() sets the poisoned flag on the page in the THP\nby TestSetPageHWPoison() before calling try_to_split_thp_page().\n\nAs suggested by David Hildenbrand, fix this panic by not accessing to the\npoisoned page in the THP during zeropage identification, while continuing\nto scan unaffected pages in the THP for possible zeropage mapping. This\nprevents a second in-kernel #MC that would cause kernel panic in Step[4].\n\nThanks to Andrew Zaborowski for his initial work on fixing this issue."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nmm: evitar el consumo de datos envenenados al dividir THP\n\nAl realizar una inyección de errores de memoria en una THP (Página Enorme Transparente) mapeada al espacio de usuario en un servidor x86, el kernel entra en pánico con el siguiente rastro. El comportamiento esperado es terminar el proceso afectado en lugar de que el kernel entre en pánico, ya que el código de Machine Check de x86 puede recuperarse de un #MC en el espacio de usuario.\n\n mce: [Error de Hardware]: CPU 0: Excepción de Machine Check: f Banco 3: bd80000000070134\n mce: [Error de Hardware]: RIP 10:<ffffffff8372f8bc> {memchr_inv+0x4c/0xf0}\n mce: [Error de Hardware]: TSC afff7bbff88a ADDR 1d301b000 MISC 80 PPIN 1e741e77539027db\n mce: [Error de Hardware]: PROCESADOR 0:d06d0 TIEMPO 1758093249 SOCKET 0 APIC 0 microcódigo 80000320\n mce: [Error de Hardware]: Ejecute lo anterior a través de 'mcelog --ascii'\n mce: [Error de Hardware]: Machine check: Carga de datos en un área irrecuperable del kernel\n Pánico del kernel - no sincronizando: Machine check local fatal\n\nLa causa raíz de este pánico es que el manejo de un fallo de memoria desencadenado por un #MC en el espacio de usuario requiere dividir la THP. El proceso de división emplea un mecanismo, implementado en try_to_map_unused_to_zeropage(), que lee las páginas en la THP para identificar páginas llenas de ceros. Sin embargo, la lectura de las páginas en la THP resulta en un segundo #MC en el kernel, que ocurre antes de que se complete el memory_failure() inicial, lo que finalmente lleva a un pánico del kernel. Vea el rastro de llamadas del pánico del kernel en los dos #MCs.\n\n Ocurre el primer Machine Check // [1]\n memory_failure() // [2]\n try_to_split_thp_page()\n split_huge_page()\n split_huge_page_to_list_to_order()\n __folio_split() // [3]\n remap_page()\n remove_migration_ptes()\n remove_migration_pte()\n try_to_map_unused_to_zeropage() // [4]\n memchr_inv() // [5]\n Ocurre el segundo Machine Check // [6]\n Pánico del kernel\n\n[1] Desencadenado al acceder a una THP envenenada por hardware en el espacio de usuario, lo cual es típicamente recuperable terminando el proceso afectado.\n\n[2] Llamar a folio_set_has_hwpoisoned() antes de try_to_split_thp_page().\n\n[3] Pasar el flag de remapeo RMP_USE_SHARED_ZEROPAGE a remap_page().\n\n[4] Intentar mapear la THP no utilizada a zeropage.\n\n[5] Volver a acceder a las páginas en la THP envenenada por hardware en el kernel.\n\n[6] Desencadenado en el kernel, lo que lleva a un pánico del kernel.\n\nEn el Paso[2], memory_failure() establece el flag de envenenamiento en la página de la THP mediante TestSetPageHWPoison() antes de llamar a try_to_split_thp_page().\n\nComo sugirió David Hildenbrand, arreglar este pánico al no acceder a la página envenenada en la THP durante la identificación de zeropage, mientras se continúa escaneando las páginas no afectadas en la THP para un posible mapeo a zeropage. Esto previene un segundo #MC en el kernel que causaría un pánico del kernel en el Paso[4].\n\nGracias a Andrew Zaborowski por su trabajo inicial en la resolución de este problema."
}
],
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "unaffected",
"programFiles": [
"mm/huge_memory.c",
"mm/migrate.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "b1f202060afeb7fcb98473929d26fd3d2093b067",
"lessThan": "6fc0a7c99e973a50018c8b4be34914a1b5c7b383",
"versionType": "git",
"status": "affected"
},
{
"version": "b1f202060afeb7fcb98473929d26fd3d2093b067",
"lessThan": "92acf4b04f255d2f0f6770bb0d0a208d8ffb2b77",
"versionType": "git",
"status": "affected"
},
{
"version": "b1f202060afeb7fcb98473929d26fd3d2093b067",
"lessThan": "841a8bfcbad94bb1ba60f59ce34f75259074ae0d",
"versionType": "git",
"status": "affected"
}
]
},
{
"vendor": "Linux",
"product": "Linux",
"defaultStatus": "affected",
"programFiles": [
"mm/huge_memory.c",
"mm/migrate.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"versions": [
{
"version": "6.12",
"status": "affected"
},
{
"version": "0",
"lessThan": "6.12",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.12.56",
"lessThanOrEqual": "6.12.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.17.6",
"lessThanOrEqual": "6.17.*",
"versionType": "semver",
"status": "unaffected"
},
{
"version": "6.18",
"lessThanOrEqual": "*",
"versionType": "original_commit_for_fix",
"status": "unaffected"
}
]
}
]
}
],
"metrics": {},
"references": [
{
"url": "https://git.kernel.org/stable/c/6fc0a7c99e973a50018c8b4be34914a1b5c7b383",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/841a8bfcbad94bb1ba60f59ce34f75259074ae0d",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/92acf4b04f255d2f0f6770bb0d0a208d8ffb2b77",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
]
}