CVE-2025-37834: Linux Kernel Privilege Escalation Flaw

CVE-2025-37834 Overview

A vulnerability has been discovered in the Linux kernel's memory management subsystem, specifically in the mm/vmscan component. The flaw occurs when the kernel attempts to reclaim hardware-poisoned (hwpoison) memory folios, leading to a kernel BUG condition. This occurs because the memory reclamation process does not properly check for hwpoison flags before attempting operations on memory pages that have been marked as corrupted.

When a dirty swapcache page is isolated by the reclaim process and subsequently marked as hardware-poisoned, the uptodate flag is cleared but the page remains in the LRU (Least Recently Used) list. Subsequent reclamation attempts on this poisoned page trigger a VM_BUG_ON_FOLIO assertion failure in add_to_swap(), causing a kernel panic.

Critical Impact

Local attackers can trigger kernel panics and system crashes by exploiting the race condition between memory failure injection and page reclamation, resulting in denial of service conditions.

Affected Products

• Linux Kernel (multiple versions)
• linux linux_kernel

Discovery Timeline

• May 8, 2025 - CVE-2025-37834 published to NVD
• November 14, 2025 - Last updated in NVD database

Technical Details for CVE-2025-37834

Vulnerability Analysis

The vulnerability resides in the shrink_folio_list() function within the kernel's memory reclamation code path. When hardware memory errors occur, the kernel marks affected pages with the hwpoison flag to prevent their use. However, the vmscan subsystem failed to check for this flag before attempting to reclaim such pages.

The exploitation scenario involves three stages: First, when a dirty swapcache page is isolated by the reclaim process (kswapd0) and the page isn't locked, a memory failure event marks the page as hwpoison. The me_swapcache_dirty() function clears the uptodate flag and attempts to delete the page from the LRU list, but this operation fails. The reclaim process then places the hwpoisoned page back into the LRU list.

Second, when the process mapping the hwpoisoned page exits, the page reference is deleted, but the page itself is never freed and remains in the LRU list indefinitely.

Third, when a subsequent reclamation cycle attempts to process this page, add_to_swap() triggers a VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) assertion at mm/swap_state.c:184, causing a kernel panic.

Root Cause

The root cause is the absence of a check for the hwpoison flag in shrink_folio_list() before attempting page reclamation operations. When me_swapcache_dirty() clears the uptodate flag on a hwpoisoned page but fails to remove it from the LRU list, the page enters an inconsistent state. The reclamation code assumes all pages in the LRU list are valid for reclamation, which is no longer true for hwpoisoned pages.

Additionally, hwpoisoned folios may not be unmapped by hwpoison_user_mappings() if the folio isn't in the LRU list at the time of the memory failure event, creating another edge case where the page remains mapped but corrupted.

Attack Vector

This vulnerability requires local access and low privileges to exploit. An attacker can trigger the vulnerability through the following sequence:

1. Allocate and map memory pages to a process
2. Cause the pages to become dirty swapcache pages
3. Trigger memory pressure to initiate page reclamation
4. Inject a memory failure event (via /sys/kernel/debug/hwpoison/ interfaces if available, or by inducing actual hardware errors)
5. Time the injection to occur while the page is isolated but not locked by the reclaim process
6. Exit the process mapping the page
7. Trigger another reclamation cycle to hit the BUG assertion

The attack results in a kernel panic, causing complete system unavailability. While this requires precise timing and local access, the reproducibility has been confirmed using the Syzkaller fuzzing framework.

Detection Methods for CVE-2025-37834

Indicators of Compromise

• Kernel panic messages containing VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) in system logs
• Crash dumps showing call traces through add_to_swap(), shrink_folio_list(), and kswapd
• System instability or unexpected reboots during high memory pressure conditions
• Memory failure messages in dmesg indicating dirty swapcache page still referenced

Detection Strategies

• Monitor kernel logs for hwpoison related error messages followed by BUG assertions
• Deploy kernel crash dump analysis to identify this specific crash signature
• Use eBPF probes to monitor for anomalous activity in memory reclamation paths
• Implement audit logging for access to hardware error injection interfaces

Monitoring Recommendations

• Configure kdump or crash kernel to capture memory dumps on panic for forensic analysis
• Set up alerts for dmesg entries containing memory failure and hwpoison keywords
• Monitor system availability metrics for unexpected restart patterns
• Track kswapd activity and memory pressure indicators alongside system stability

How to Mitigate CVE-2025-37834

Immediate Actions Required

• Update to patched Linux kernel versions that include the fix
• Restrict access to hardware error injection interfaces (/sys/kernel/debug/hwpoison/)
• Ensure only trusted users have local system access
• Consider limiting memory pressure scenarios in sensitive environments until patching is complete

Patch Information

The fix modifies shrink_folio_list() to skip hwpoisoned pages during reclamation. Additionally, the patch ensures hwpoisoned folios are unmapped in shrink_folio_list() to prevent failures in hwpoison_user_mappings() when the folio isn't in the LRU list.

Official patches are available through the following kernel commits:

• Kernel Commit 1b0449544c6482179ac84530b61fc192a6527bfd
• Kernel Commit 1c9798bf8145a92abf45aa9d38a6406d9eb8bdf0
• Kernel Commit 912e9f0300c3564b72a8808db406e313193a37ad

Workarounds

• Restrict local access to the system to trusted administrators only
• Disable or restrict access to debugfs hwpoison interfaces if not required for operations
• Monitor and alert on memory failure events to quickly identify potential exploitation attempts
• Consider deploying additional kernel hardening measures such as KASLR and stack protectors

# Restrict access to hwpoison debug interfaces
chmod 600 /sys/kernel/debug/hwpoison/*

# Monitor for memory failure events
dmesg -w | grep -i "memory failure\|hwpoison"