CVE-2025-37834

  1. OpenCVE
  2. Vulnerabilities (CVE)
  3. CVE-2025-37834
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.

5.5 /10

CVSS v3 : MEDIUM

V3 Legend

Vector :

Exploitability : 1.8 / Impact : 3.6

Attack Vector LOCAL

Attack Complexity LOW

Privileges Required LOW

User Interaction NONE

Confidentiality Impact NONE

Integrity Impact NONE

Availability Impact HIGH

Scope UNCHANGED

References
Link Resource
https://git.kernel.org/stable/c/1b0449544c6482179ac84530b61fc192a6527bfd Patch
https://git.kernel.org/stable/c/1c9798bf8145a92abf45aa9d38a6406d9eb8bdf0 Patch
https://git.kernel.org/stable/c/912e9f0300c3564b72a8808db406e313193a37ad Patch
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
History

14 Nov 2025, 19:48

Type Values Removed Values Added
CPE cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
References () https://git.kernel.org/stable/c/1b0449544c6482179ac84530b61fc192a6527bfd - () https://git.kernel.org/stable/c/1b0449544c6482179ac84530b61fc192a6527bfd - Patch
References () https://git.kernel.org/stable/c/1c9798bf8145a92abf45aa9d38a6406d9eb8bdf0 - () https://git.kernel.org/stable/c/1c9798bf8145a92abf45aa9d38a6406d9eb8bdf0 - Patch
References () https://git.kernel.org/stable/c/912e9f0300c3564b72a8808db406e313193a37ad - () https://git.kernel.org/stable/c/912e9f0300c3564b72a8808db406e313193a37ad - Patch
CWE NVD-CWE-noinfo
CVSS v2 : unknown
v3 : unknown 		v2 : unknown
v3 : 5.5
First Time Linux
Linux linux Kernel

08 May 2025, 14:39

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/vmscan: no intente reclamar el folio hwpoison Syzkaller informa un error de la siguiente manera: Error de inyección de memoria para pfn 0x18b00e en la dirección virtual del proceso 0x20ffd000 Error de memoria: 0x18b00e: 2 usuarios aún hacen referencia a la página de swapcache sucia Error de memoria: 0x18b00e: acción de recuperación para la página de swapcache sucia: Página con errores: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(bloqueado|sucio|arch_1|swapbacked|hwpoison|nodo=0|zona=2|lastcpupid=0xfffff) sin procesar: 005ffffe00482011 muerto000000000100 muerto000000000122 ffff0000e232a7c9 sin procesar: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 página volcada porque: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cortar aquí ]------------ ¡ERROR del kernel en mm/swap_state.c:184! Error interno: Ups - BUG: 00000000f2000800 [#1] Módulos SMP vinculados: CPU: 0 PID: 60 Comm: kswapd0 No contaminado 6.6.0-gcb097e7de84e #3 Nombre del hardware: 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: 000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9: dfff800000000000 x8: 00009fffc9274686 x7: ffff0001b6c5cbd3 x6: 000000000000001 x5: ffff0000c25896c0 x4: 0000000000000000 x3: 00000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Rastreo de llamadas: 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 Puedo reproducir este problema con los siguientes pasos: 1) Cuando una página de caché de intercambio sucia es aislada por el proceso de recuperación y la página no está bloqueada, se inyecta un fallo de memoria para la página. me_swapcache_dirty() borra el indicador de actualización e intenta eliminarla de la unidad de recuperación (LRU), pero falla. El proceso de recuperación devolverá la página contaminada a la LRU. 2) El proceso que asigna la página contaminada sale, la página se elimina, la página nunca se liberará y permanecerá en la LRU para siempre. 3) Si activamos una recuperación de nuevo e intentamos recuperar la página, add_to_swap() activará VM_BUG_ON_FOLIO debido a que el indicador de actualización está borrado. Para solucionarlo, omita la página contaminada en la lista de recuperación (shrink_folio_list()). Además, es posible que el folio hwpoison aún no esté desasignado por hwpoison_user_mappings(), desasignelo en shrink_folio_list(), de lo contrario el folio no podrá ser desasignado por hwpoison_user_mappings() ya que el folio no está en la lista lru.

08 May 2025, 07:15

Type Values Removed Values Added
New CVE
Information

Published : 2025-05-08 07:15

Updated : 2025-11-14 19:48

NVD link : CVE-2025-37834

Mitre link : CVE-2025-37834

CVE.ORG link : CVE-2025-37834

JSON object : View

Products Affected

linux

  • linux_kernel
CWE
NVD-CWE-noinfo