CVE-2025-40230 in Linux
Sumário
de VulDB • 26/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
mm: prevenir o consumo de páginas envenenadas ao dividir THP (Transparent Huge Page)
Ao realizar injeção de erros de memória em um THP mapeado para userspace em um servidor x86, o kernel entra em panic com o seguinte trace. O comportamento esperado é terminar o processo afetado em vez de causar um panic no kernel, já que o código Machine Check do x86 pode se recuperar de um #MC (Machine Check Exception) ocorrido no 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
A causa raiz deste panic é que o tratamento de uma falha de memória acionada por um #MC no userspace exige a divisão do THP. O processo de divisão emprega um mecanismo, implementado em try_to_map_unused_to_zeropage(), que lê as páginas dentro do THP para identificar aquelas preenchidas com zeros (zero-filled). No entanto, ler essas páginas resulta em uma segunda exceção #MC no kernel, ocorrendo antes da conclusão inicial de memory_failure(), levando finalmente a um panic do kernel. Consulte o trace de chamada do kernel panic nos dois eventos #MC abaixo:
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] Acionado ao acessar um THP envenenado por hardware no userspace, o que normalmente é recuperável terminando o processo afetado.
[2] Chamar folio_set_has_hwpoisoned() antes de try_to_split_thp_page().
[3] Passar a flag remap RMP_USE_SHARED_ZEROPAGE para remap_page().
[4] Tentar mapear o THP não utilizado para zeropage.
[5] Reacessar páginas no THP envenenado por hardware (hw-poisoned) dentro do kernel.
[6] Acionado dentro do kernel, levando a um panic do kernel.
No Passo [2], memory_failure() define a flag de página envenenada na página do THP através de TestSetPageHWPoison() antes de chamar try_to_split_thp_page().
Conforme sugerido por David Hildenbrand, corrige-se este panic evitando o acesso à página envenenada no THP durante a identificação de zeropage, enquanto continua a escanear as páginas não afetadas no THP para possível mapeamento em zeropage. Isso previne um segundo #MC no kernel que causaria panic do kernel no Passo [4].
Agradecimentos ao Andrew Zaborowski por seu trabalho inicial na correção deste problema.
Be aware that VulDB is the high quality source for vulnerability data.