Skip to content
Fencer Vulns
no cvss —

CVE-2025-40230 json

mm: prevent poison consumption when splitting THP

published 2025-12-04 11 mo ago modified 2026-10-19 20 d ago also EUVD-2025-201229

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 13%
public exploits
0
none known

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.

Patch / fix

  • Linux Linux 6.12.56, 6.17.6, 6.18
  • linux Debian 13 6.12.57-1
  • linux Debian 14 6.17.6-1

debian advisories DEBIAN-CVE-2025-40230

  • linux Ubuntu 25.10 6.17.0-14.14
  • linux-aws Ubuntu 25.10 6.17.0-1007.7
  • linux-gcp Ubuntu 25.10 6.17.0-1007.7
  • linux-azure Ubuntu 25.10 6.17.0-1008.8
  • linux-raspi Ubuntu 25.10 6.17.0-1008.8
  • linux-riscv Ubuntu 25.10 6.17.0-14.14.1
  • linux-oracle Ubuntu 25.10 6.17.0-1007.7
  • linux-aws-6.17 Ubuntu 24.04 LTS 6.17.0-1007.7~24.04.1

ubuntu advisories UBUNTU-CVE-2025-40230

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • kernel-syms SLES 16.0, Linux Micro Extras 6.2, SLES for SAP applications 16.0 6.12.0-160000.27.1
  • kernel-obs-build Linux Micro Extras 6.2 6.12.0-160000.27.1
  • kernel-rt Linux Micro 6.2 6.12.0-160000.27.1
  • kernel-64kb SLES 16.0, Linux Micro 6.2, SLES for SAP applications 16.0 6.12.0-160000.27.1
  • kernel-source SLES 16.0, Linux Micro 6.2, SLES for SAP applications 16.0 6.12.0-160000.27.1
  • kernel-default SLES 16.0, Linux Micro 6.2, SLES for SAP applications 16.0 6.12.0-160000.27.1
  • kernel-default-base SLES 16.0, Linux Micro 6.2, SLES for SAP applications 16.0 6.12.0-160000.27.1.160000.2.8
  • kernel-azure SLES for SAP applications 16.0, SLES 16.0 6.12.0-160000.27.1

suse advisories SUSE-SU-2026:20873-1SUSE-SU-2026:20838-1SUSE-SU-2026:20931-1

  • kernel-rt openSUSE Leap 16.0 6.12.0-160000.27.1
  • dtb-aarch64 openSUSE Leap 16.0 6.12.0-160000.27.1
  • kernel-64kb openSUSE Leap 16.0 6.12.0-160000.27.1
  • kernel-syms openSUSE Leap 16.0 6.12.0-160000.27.1
  • kernel-azure openSUSE Leap 16.0 6.12.0-160000.27.1
  • kernel-obs-qa openSUSE Leap 16.0 6.12.0-160000.27.1
  • kernel-source openSUSE Leap 16.0 6.12.0-160000.27.1
  • kernel-default openSUSE Leap 16.0 6.12.0-160000.27.1

opensuse advisories openSUSE-SU-2026:20416-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2025-40230 updated cvss 5.9

kernel: mm: prevent poison consumption when splitting THP

  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more
    affected: workaround, no fix planned “Out of support scope”
  • Red Hat Enterprise Linux 10 kernel
    affected: workaround, no fix available
  • Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +83 more
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

Exploit prediction

0.23% chance of exploitation in the next 30 days, higher than 13% of all scored CVEs (FIRST EPSS, 2026-11-08).

Affected products

  • Linux Linux

Classification

Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.