CVE-2025-40230
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-12-04

Last updated on: 2025-12-04

Assigner: kernel.org

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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-04
Last Modified
2025-12-04
Generated
2026-05-07
AI Q&A
2025-12-04
EPSS Evaluated
2026-05-05
NVD
CVE-2025-40230
EUVD
EUVD-2025-201229
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability occurs in the Linux kernel when handling memory error injection on a Transparent Huge Page (THP) mapped to userspace on an x86 server. Normally, if a hardware-poisoned THP is accessed, the affected process should be terminated. However, due to the way the kernel splits the THP during error handling, it reads pages in the THP to identify zero-filled pages. This reading triggers a second machine check exception (#MC) inside the kernel before the initial memory failure handling completes, causing a kernel panic instead of safely terminating the process. The fix prevents accessing the poisoned page during this zero-page identification, avoiding the second machine check and kernel panic.


How can this vulnerability impact me? :

This vulnerability can cause the entire Linux kernel to panic (crash) when a hardware-poisoned Transparent Huge Page is accessed, instead of just terminating the affected userspace process. This kernel panic leads to system downtime and potential data loss or service interruption, impacting system stability and availability.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as a kernel panic triggered by a Machine Check Exception (MCE) when performing memory error injection on a Transparent Huge Page (THP) mapped to userspace on an x86 server. Detection involves monitoring for kernel panic logs with MCE hardware error messages similar to the following: mce: [Hardware Error]: CPU 0: Machine Check Exception: f Bank 3: bd80000000070134 mce: [Hardware Error]: RIP 10:<ffffffff8372f8bc> {memchr_inv+0x4c/0xf0} Kernel panic - not syncing: Fatal local machine check You can use the command `dmesg` or check `/var/log/kern.log` or `/var/log/messages` for such MCE errors and kernel panic traces. Additionally, running `mcelog --ascii` on the logged MCE data can help interpret the hardware error details.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves updating the Linux kernel to a version where this vulnerability is fixed. The fix prevents the kernel panic by avoiding access to poisoned pages during zeropage identification when splitting THPs. Until the patch is applied, monitor for kernel panics related to MCEs and consider disabling Transparent Huge Pages (THP) as a temporary workaround to reduce the risk of triggering this issue.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart