CVE-2025-37834 (GCVE-0-2025-37834)
Vulnerability from cvelistv5
Published
2025-05-08 06:26
Modified
2025-05-26 05:21
Severity ?
VLAI Severity ?
EPSS score ?
Summary
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.
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"mm/vmscan.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "1c9798bf8145a92abf45aa9d38a6406d9eb8bdf0",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "912e9f0300c3564b72a8808db406e313193a37ad",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "1b0449544c6482179ac84530b61fc192a6527bfd",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"mm/vmscan.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.26",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.14.*",
"status": "unaffected",
"version": "6.14.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.15",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.26",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: don\u0027t try to reclaim hwpoison folio\n\nSyzkaller reports a bug as follows:\n\nInjecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000\nMemory failure: 0x18b00e: dirty swapcache page still referenced by 2 users\nMemory failure: 0x18b00e: recovery action for dirty swapcache page: Failed\npage: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e\nmemcg:ffff0000dd6d9000\nanon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff)\nraw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9\nraw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000\npage dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio))\n------------[ cut here ]------------\nkernel BUG at mm/swap_state.c:184!\nInternal error: Oops - BUG: 00000000f2000800 [#1] SMP\nModules linked in:\nCPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3\nHardware name: linux,dummy-virt (DT)\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : add_to_swap+0xbc/0x158\nlr : add_to_swap+0xbc/0x158\nsp : ffff800087f37340\nx29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780\nx26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0\nx23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4\nx20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000\nx17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c\nx14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b\nx11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000\nx8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001\nx5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000\nCall trace:\n add_to_swap+0xbc/0x158\n shrink_folio_list+0x12ac/0x2648\n shrink_inactive_list+0x318/0x948\n shrink_lruvec+0x450/0x720\n shrink_node_memcgs+0x280/0x4a8\n shrink_node+0x128/0x978\n balance_pgdat+0x4f0/0xb20\n kswapd+0x228/0x438\n kthread+0x214/0x230\n ret_from_fork+0x10/0x20\n\nI can reproduce this issue with the following steps:\n\n1) When a dirty swapcache page is isolated by reclaim process and the\n page isn\u0027t locked, inject memory failure for the page. \n me_swapcache_dirty() clears uptodate flag and tries to delete from lru,\n but fails. Reclaim process will put the hwpoisoned page back to lru.\n\n2) The process that maps the hwpoisoned page exits, the page is deleted\n the page will never be freed and will be in the lru forever.\n\n3) If we trigger a reclaim again and tries to reclaim the page,\n add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is\n cleared.\n\nTo fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the\nhwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap\nit in shrink_folio_list(), otherwise the folio will fail to be unmaped by\nhwpoison_user_mappings() since the folio isn\u0027t in lru list."
}
],
"providerMetadata": {
"dateUpdated": "2025-05-26T05:21:56.229Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/1c9798bf8145a92abf45aa9d38a6406d9eb8bdf0"
},
{
"url": "https://git.kernel.org/stable/c/912e9f0300c3564b72a8808db406e313193a37ad"
},
{
"url": "https://git.kernel.org/stable/c/1b0449544c6482179ac84530b61fc192a6527bfd"
}
],
"title": "mm/vmscan: don\u0027t try to reclaim hwpoison folio",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-37834",
"datePublished": "2025-05-08T06:26:24.463Z",
"dateReserved": "2025-04-16T04:51:23.951Z",
"dateUpdated": "2025-05-26T05:21:56.229Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2025-37834\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-05-08T07:15:54.627\",\"lastModified\":\"2025-05-08T14:39:09.683\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nmm/vmscan: don\u0027t try to reclaim hwpoison folio\\n\\nSyzkaller reports a bug as follows:\\n\\nInjecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000\\nMemory failure: 0x18b00e: dirty swapcache page still referenced by 2 users\\nMemory failure: 0x18b00e: recovery action for dirty swapcache page: Failed\\npage: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e\\nmemcg:ffff0000dd6d9000\\nanon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff)\\nraw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9\\nraw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000\\npage dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio))\\n------------[ cut here ]------------\\nkernel BUG at mm/swap_state.c:184!\\nInternal error: Oops - BUG: 00000000f2000800 [#1] SMP\\nModules linked in:\\nCPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3\\nHardware name: linux,dummy-virt (DT)\\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\\npc : add_to_swap+0xbc/0x158\\nlr : add_to_swap+0xbc/0x158\\nsp : ffff800087f37340\\nx29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780\\nx26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0\\nx23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4\\nx20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000\\nx17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c\\nx14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b\\nx11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000\\nx8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001\\nx5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000\\nx2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000\\nCall trace:\\n add_to_swap+0xbc/0x158\\n shrink_folio_list+0x12ac/0x2648\\n shrink_inactive_list+0x318/0x948\\n shrink_lruvec+0x450/0x720\\n shrink_node_memcgs+0x280/0x4a8\\n shrink_node+0x128/0x978\\n balance_pgdat+0x4f0/0xb20\\n kswapd+0x228/0x438\\n kthread+0x214/0x230\\n ret_from_fork+0x10/0x20\\n\\nI can reproduce this issue with the following steps:\\n\\n1) When a dirty swapcache page is isolated by reclaim process and the\\n page isn\u0027t locked, inject memory failure for the page. \\n me_swapcache_dirty() clears uptodate flag and tries to delete from lru,\\n but fails. Reclaim process will put the hwpoisoned page back to lru.\\n\\n2) The process that maps the hwpoisoned page exits, the page is deleted\\n the page will never be freed and will be in the lru forever.\\n\\n3) If we trigger a reclaim again and tries to reclaim the page,\\n add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is\\n cleared.\\n\\nTo fix it, skip the hwpoisoned page in shrink_folio_list(). Besides, the\\nhwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap\\nit in shrink_folio_list(), otherwise the folio will fail to be unmaped by\\nhwpoison_user_mappings() since the folio isn\u0027t in lru list.\"},{\"lang\":\"es\",\"value\":\"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\u00f3n de memoria para pfn 0x18b00e en la direcci\u00f3n virtual del proceso 0x20ffd000 Error de memoria: 0x18b00e: 2 usuarios a\u00fan hacen referencia a la p\u00e1gina de swapcache sucia Error de memoria: 0x18b00e: acci\u00f3n de recuperaci\u00f3n para la p\u00e1gina de swapcache sucia: P\u00e1gina 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\u00e1gina volcada porque: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cortar aqu\u00ed ]------------ \u00a1ERROR del kernel en mm/swap_state.c:184! Error interno: Ups - BUG: 00000000f2000800 [#1] M\u00f3dulos 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\u00e1gina de cach\u00e9 de intercambio sucia es aislada por el proceso de recuperaci\u00f3n y la p\u00e1gina no est\u00e1 bloqueada, se inyecta un fallo de memoria para la p\u00e1gina. me_swapcache_dirty() borra el indicador de actualizaci\u00f3n e intenta eliminarla de la unidad de recuperaci\u00f3n (LRU), pero falla. El proceso de recuperaci\u00f3n devolver\u00e1 la p\u00e1gina contaminada a la LRU. 2) El proceso que asigna la p\u00e1gina contaminada sale, la p\u00e1gina se elimina, la p\u00e1gina nunca se liberar\u00e1 y permanecer\u00e1 en la LRU para siempre. 3) Si activamos una recuperaci\u00f3n de nuevo e intentamos recuperar la p\u00e1gina, add_to_swap() activar\u00e1 VM_BUG_ON_FOLIO debido a que el indicador de actualizaci\u00f3n est\u00e1 borrado. Para solucionarlo, omita la p\u00e1gina contaminada en la lista de recuperaci\u00f3n (shrink_folio_list()). Adem\u00e1s, es posible que el folio hwpoison a\u00fan no est\u00e9 desasignado por hwpoison_user_mappings(), desasignelo en shrink_folio_list(), de lo contrario el folio no podr\u00e1 ser desasignado por hwpoison_user_mappings() ya que el folio no est\u00e1 en la lista lru.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/1b0449544c6482179ac84530b61fc192a6527bfd\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/1c9798bf8145a92abf45aa9d38a6406d9eb8bdf0\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/912e9f0300c3564b72a8808db406e313193a37ad\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…