CVE-2025-40230 (GCVE-0-2025-40230)
Vulnerability from cvelistv5
Published
2025-12-04 15:31
Modified
2025-12-04 15:31
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
Impacted products
Vendor Product Version
Linux Linux Version: b1f202060afeb7fcb98473929d26fd3d2093b067
Version: b1f202060afeb7fcb98473929d26fd3d2093b067
Version: b1f202060afeb7fcb98473929d26fd3d2093b067
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "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"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.56",
                  "versionStartIncluding": "6.12",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.17.6",
                  "versionStartIncluding": "6.12",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18",
                  "versionStartIncluding": "6.12",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "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."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-12-04T15:31:21.369Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/6fc0a7c99e973a50018c8b4be34914a1b5c7b383"
        },
        {
          "url": "https://git.kernel.org/stable/c/92acf4b04f255d2f0f6770bb0d0a208d8ffb2b77"
        },
        {
          "url": "https://git.kernel.org/stable/c/841a8bfcbad94bb1ba60f59ce34f75259074ae0d"
        }
      ],
      "title": "mm: prevent poison consumption when splitting THP",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-40230",
    "datePublished": "2025-12-04T15:31:21.369Z",
    "dateReserved": "2025-04-16T07:20:57.180Z",
    "dateUpdated": "2025-12-04T15:31:21.369Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-40230\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-12-04T16:16:15.720\",\"lastModified\":\"2025-12-04T17:15:08.283\",\"vulnStatus\":\"Awaiting Analysis\",\"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.\"}],\"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\"}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.