FKIE_CVE-2025-40230

Vulnerability from fkie_nvd - Published: 2025-12-04 16:16 - Updated: 2026-10-19 21:10
Severity
Summary
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.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/6fc0a7c99e973a50018c8b4be34914a1b5c7b383
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/841a8bfcbad94bb1ba60f59ce34f75259074ae0d
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/92acf4b04f255d2f0f6770bb0d0a208d8ffb2b77
Impacted products
Vendor Product Version
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "mm/huge_memory.c",
            "mm/migrate.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "6fc0a7c99e973a50018c8b4be34914a1b5c7b383",
              "status": "affected",
              "version": "b1f202060afeb7fcb98473929d26fd3d2093b067",
              "versionType": "git"
            },
            {
              "lessThan": "92acf4b04f255d2f0f6770bb0d0a208d8ffb2b77",
              "status": "affected",
              "version": "b1f202060afeb7fcb98473929d26fd3d2093b067",
              "versionType": "git"
            },
            {
              "lessThan": "841a8bfcbad94bb1ba60f59ce34f75259074ae0d",
              "status": "affected",
              "version": "b1f202060afeb7fcb98473929d26fd3d2093b067",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "mm/huge_memory.c",
            "mm/migrate.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "6.12"
            },
            {
              "lessThan": "6.12",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.56",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.17.*",
              "status": "unaffected",
              "version": "6.17.6",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.18",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "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:\u003cffffffff8372f8bc\u003e {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 \u0027mcelog --ascii\u0027\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\u00f3n de errores de memoria en una THP (P\u00e1gina Enorme Transparente) mapeada al espacio de usuario en un servidor x86, el kernel entra en p\u00e1nico con el siguiente rastro. El comportamiento esperado es terminar el proceso afectado en lugar de que el kernel entre en p\u00e1nico, ya que el c\u00f3digo de Machine Check de x86 puede recuperarse de un #MC en el espacio de usuario.\n\n  mce: [Error de Hardware]: CPU 0: Excepci\u00f3n de Machine Check: f Banco 3: bd80000000070134\n  mce: [Error de Hardware]: RIP 10:\u003cffffffff8372f8bc\u003e {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\u00f3digo 80000320\n  mce: [Error de Hardware]: Ejecute lo anterior a trav\u00e9s de \u0027mcelog --ascii\u0027\n  mce: [Error de Hardware]: Machine check: Carga de datos en un \u00e1rea irrecuperable del kernel\n  P\u00e1nico del kernel - no sincronizando: Machine check local fatal\n\nLa causa ra\u00edz de este p\u00e1nico 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\u00f3n emplea un mecanismo, implementado en try_to_map_unused_to_zeropage(), que lee las p\u00e1ginas en la THP para identificar p\u00e1ginas llenas de ceros. Sin embargo, la lectura de las p\u00e1ginas 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\u00e1nico del kernel. Vea el rastro de llamadas del p\u00e1nico 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\u00e1nico del kernel\n\n[1] Desencadenado al acceder a una THP envenenada por hardware en el espacio de usuario, lo cual es t\u00edpicamente 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\u00e1ginas en la THP envenenada por hardware en el kernel.\n\n[6] Desencadenado en el kernel, lo que lleva a un p\u00e1nico del kernel.\n\nEn el Paso[2], memory_failure() establece el flag de envenenamiento en la p\u00e1gina de la THP mediante TestSetPageHWPoison() antes de llamar a try_to_split_thp_page().\n\nComo sugiri\u00f3 David Hildenbrand, arreglar este p\u00e1nico al no acceder a la p\u00e1gina envenenada en la THP durante la identificaci\u00f3n de zeropage, mientras se contin\u00faa escaneando las p\u00e1ginas no afectadas en la THP para un posible mapeo a zeropage. Esto previene un segundo #MC en el kernel que causar\u00eda un p\u00e1nico del kernel en el Paso[4].\n\nGracias a Andrew Zaborowski por su trabajo inicial en la resoluci\u00f3n de este problema."
    }
  ],
  "id": "CVE-2025-40230",
  "lastModified": "2026-10-19T21:10:00.160",
  "metrics": {},
  "published": "2025-12-04T16:16:15.720",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "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"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Deferred"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.