CVE-2025-37834 in Linux
Summary
by MITRE • 05/08/2025
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: don't try to reclaim hwpoison folio
Syzkaller reports a bug as follows:
Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000 Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff) raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9 raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cut here ]------------
kernel BUG at mm/swap_state.c:184! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
Modules linked in: CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3 Hardware name: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : add_to_swap+0xbc/0x158 lr : add_to_swap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001 x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Call trace: add_to_swap+0xbc/0x158 shrink_folio_list+0x12ac/0x2648 shrink_inactive_list+0x318/0x948 shrink_lruvec+0x450/0x720 shrink_node_memcgs+0x280/0x4a8 shrink_node+0x128/0x978 balance_pgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214/0x230 ret_from_fork+0x10/0x20
I can reproduce this issue with the following steps:
1) When a dirty swapcache page is isolated by reclaim process and the page isn't locked, inject memory failure for the page. me_swapcache_dirty() clears uptodate flag and tries to delete from lru, but fails. Reclaim process will put the hwpoisoned page back to lru.
2) The process that maps the hwpoisoned page exits, the page is deleted the page will never be freed and will be in the lru forever.
3) If we trigger a reclaim again and tries to reclaim the page, add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is cleared.
To fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap it in shrink_folio_list(), otherwise the folio will fail to be unmaped by hwpoison_user_mappings() since the folio isn't in lru list.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 03/14/2026
The vulnerability described in CVE-2025-37834 resides within the Linux kernel's memory management subsystem, specifically in the virtual memory scanning mechanism known as vmscan. This flaw manifests when the kernel attempts to reclaim memory pages that have been marked as hardware poisoned, leading to a kernel panic and system instability. The issue occurs during the process of memory failure handling where a dirty swapcache page is isolated for reclaimation but subsequently fails to be properly managed due to its hardware poisoned state. The syzkaller fuzzing tool has identified this as a critical condition that results in a kernel BUG, indicating a fundamental flaw in the kernel's handling of memory failure scenarios for pages that are already marked as hardware poisoned.
The technical root cause of this vulnerability stems from the improper handling of hardware poisoned folios during memory reclaim operations. When a dirty swapcache page is identified as hardware poisoned, the system attempts to clear its uptodate flag and remove it from the LRU (Least Recently Used) list through the me_swapcache_dirty() function. However, this process fails to completely isolate the page, leaving it in a state where it can be re-added to the LRU list by the reclaim process. This creates a circular dependency where the poisoned page remains in memory indefinitely, unable to be properly freed or unmapped. The kernel's shrink_folio_list() function, which is responsible for managing memory reclaim operations, does not account for pages that are marked as hardware poisoned, leading to a direct violation of kernel assertions when attempting to add such pages back to swap. This behavior violates the fundamental principle of memory management where poisoned pages should be immediately isolated and not subject to normal reclaim operations.
The operational impact of this vulnerability is severe and can lead to system instability, memory leaks, and potential denial of service conditions. The kernel panic occurs when the add_to_swap() function encounters a hardware poisoned folio that has had its uptodate flag cleared but is still being processed for swap operations. This creates an inconsistent state where the kernel's memory management subsystem fails to properly handle memory failure recovery, resulting in a kernel BUG that terminates the reclaim process. The affected system may experience complete system crashes or become unresponsive, particularly under memory pressure conditions where the reclaim mechanism is actively working to free memory. Additionally, the memory leak occurs as the poisoned page remains indefinitely in the LRU list, consuming memory resources without proper cleanup, which can compound over time and lead to system memory exhaustion.
The fix implemented for this vulnerability involves modifying the shrink_folio_list() function to explicitly skip hardware poisoned pages during memory reclaim operations. This approach prevents the kernel from attempting to process poisoned pages through normal swap operations, thereby avoiding the kernel BUG that occurs when the uptodate flag is checked. The solution also includes ensuring that hardware poisoned folios are properly unmapped within the shrink_folio_list() function before attempting to reclaim them, addressing the issue where the hwpoison_user_mappings() function fails to properly unmap pages that are no longer in the LRU list. This mitigation aligns with the ATT&CK framework's memory corruption techniques by preventing improper memory handling that could lead to system instability, and follows CWE guidelines for proper handling of memory failure conditions. The fix ensures that hardware poisoned pages are immediately isolated from normal memory management operations, preventing the inconsistent state that leads to kernel panics and maintaining system stability under memory failure conditions.
This vulnerability demonstrates the critical importance of proper memory failure handling in kernel space operations and the potential for seemingly isolated memory management issues to cascade into system-wide failures. The fix addresses a fundamental gap in the kernel's memory management logic, ensuring that pages marked as hardware poisoned are handled appropriately and do not interfere with normal memory reclaim operations. The solution represents a defensive programming approach that prevents invalid memory operations while maintaining system stability. This type of vulnerability highlights the complexity of kernel memory management and the need for comprehensive testing of edge cases involving memory failure scenarios, particularly in virtual memory subsystems where multiple processes and memory management operations interact simultaneously. The mitigation strategy follows established security practices by ensuring that hardware poisoned pages are properly isolated from normal system operations, preventing both immediate kernel panics and long-term memory leaks that could compromise system reliability.