CVE-2025-37834

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmscan: don&amp;#39;t try to reclaim hwpoison folio<br /> <br /> Syzkaller reports a bug as follows:<br /> <br /> Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000<br /> Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users<br /> Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed<br /> page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e<br /> memcg:ffff0000dd6d9000<br /> anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff)<br /> raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9<br /> raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000<br /> page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio))<br /> ------------[ cut here ]------------<br /> kernel BUG at mm/swap_state.c:184!<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] SMP<br /> Modules linked in:<br /> CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : add_to_swap+0xbc/0x158<br /> lr : add_to_swap+0xbc/0x158<br /> sp : ffff800087f37340<br /> x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780<br /> x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0<br /> x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4<br /> x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000<br /> x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c<br /> x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b<br /> x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000<br /> x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001<br /> x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000<br /> Call trace:<br /> add_to_swap+0xbc/0x158<br /> shrink_folio_list+0x12ac/0x2648<br /> shrink_inactive_list+0x318/0x948<br /> shrink_lruvec+0x450/0x720<br /> shrink_node_memcgs+0x280/0x4a8<br /> shrink_node+0x128/0x978<br /> balance_pgdat+0x4f0/0xb20<br /> kswapd+0x228/0x438<br /> kthread+0x214/0x230<br /> ret_from_fork+0x10/0x20<br /> <br /> I can reproduce this issue with the following steps:<br /> <br /> 1) When a dirty swapcache page is isolated by reclaim process and the<br /> page isn&amp;#39;t locked, inject memory failure for the page. <br /> me_swapcache_dirty() clears uptodate flag and tries to delete from lru,<br /> but fails. Reclaim process will put the hwpoisoned page back to lru.<br /> <br /> 2) The process that maps the hwpoisoned page exits, the page is deleted<br /> the page will never be freed and will be in the lru forever.<br /> <br /> 3) If we trigger a reclaim again and tries to reclaim the page,<br /> add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is<br /> cleared.<br /> <br /> To fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the<br /> hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap<br /> it in shrink_folio_list(), otherwise the folio will fail to be unmaped by<br /> hwpoison_user_mappings() since the folio isn&amp;#39;t in lru list.