CVE-2025-21860

In the Linux kernel, the following vulnerability has been resolved: mm/zswap: fix inconsistency when zswap_store_page() fails Commit b7c0ccdfbafd ("mm: zswap: support large folios in zswap_store()") skips charging any zswap entries when it failed to zswap the entire folio. However, when some base pages are zswapped but it failed to zswap the entire folio, the zswap operation is rolled back. When freeing zswap entries for those pages, zswap_entry_free() uncharges the zswap entries that were not previously charged, causing zswap charging to become inconsistent. This inconsistency triggers two warnings with following steps: # On a machine with 64GiB of RAM and 36GiB of zswap $ stress-ng --bigheap 2 # wait until the OOM-killer kills stress-ng $ sudo reboot The two warnings are: in mm/memcontrol.c:163, function obj_cgroup_release(): WARN_ON_ONCE(nr_bytes & (PAGE_SIZE - 1)); in mm/page_counter.c:60, function page_counter_cancel(): if (WARN_ONCE(new < 0, "page_counter underflow: %ld nr_pages=%lu\n", new, nr_pages)) zswap_stored_pages also becomes inconsistent in the same way. As suggested by Kanchana, increment zswap_stored_pages and charge zswap entries within zswap_store_page() when it succeeds. This way, zswap_entry_free() will decrement the counter and uncharge the entries when it failed to zswap the entire folio. While this could potentially be optimized by batching objcg charging and incrementing the counter, let's focus on fixing the bug this time and leave the optimization for later after some evaluation. After resolving the inconsistency, the warnings disappear. [42.hyeyoo@gmail.com: refactor zswap_store_page()]
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.14:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.14:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.14:rc3:*:*:*:*:*:*

History

16 Apr 2025, 19:15

Type Values Removed Values Added
Summary (en) In the Linux kernel, the following vulnerability has been resolved: mm/zswap: fix inconsistency when zswap_store_page() fails Commit b7c0ccdfbafd ("mm: zswap: support large folios in zswap_store()") skips charging any zswap entries when it failed to zswap the entire folio. However, when some base pages are zswapped but it failed to zswap the entire folio, the zswap operation is rolled back. When freeing zswap entries for those pages, zswap_entry_free() uncharges the zswap entries that were not previously charged, causing zswap charging to become inconsistent. This inconsistency triggers two warnings with following steps: # On a machine with 64GiB of RAM and 36GiB of zswap $ stress-ng --bigheap 2 # wait until the OOM-killer kills stress-ng $ sudo reboot The two warnings are: in mm/memcontrol.c:163, function obj_cgroup_release(): WARN_ON_ONCE(nr_bytes & (PAGE_SIZE - 1)); in mm/page_counter.c:60, function page_counter_cancel(): if (WARN_ONCE(new < 0, "page_counter underflow: %ld nr_pages=%lu\n", new, nr_pages)) zswap_stored_pages also becomes inconsistent in the same way. As suggested by Kanchana, increment zswap_stored_pages and charge zswap entries within zswap_store_page() when it succeeds. This way, zswap_entry_free() will decrement the counter and uncharge the entries when it failed to zswap the entire folio. While this could potentially be optimized by batching objcg charging and incrementing the counter, let's focus on fixing the bug this time and leave the optimization for later after some evaluation. After resolving the inconsistency, the warnings disappear. [42.hyeyoo@gmail.com: refactor zswap_store_page()] Link: https://lkml.kernel.org/r/20250131082037.2426-1-42.hyeyoo@gmail.com (en) In the Linux kernel, the following vulnerability has been resolved: mm/zswap: fix inconsistency when zswap_store_page() fails Commit b7c0ccdfbafd ("mm: zswap: support large folios in zswap_store()") skips charging any zswap entries when it failed to zswap the entire folio. However, when some base pages are zswapped but it failed to zswap the entire folio, the zswap operation is rolled back. When freeing zswap entries for those pages, zswap_entry_free() uncharges the zswap entries that were not previously charged, causing zswap charging to become inconsistent. This inconsistency triggers two warnings with following steps: # On a machine with 64GiB of RAM and 36GiB of zswap $ stress-ng --bigheap 2 # wait until the OOM-killer kills stress-ng $ sudo reboot The two warnings are: in mm/memcontrol.c:163, function obj_cgroup_release(): WARN_ON_ONCE(nr_bytes & (PAGE_SIZE - 1)); in mm/page_counter.c:60, function page_counter_cancel(): if (WARN_ONCE(new < 0, "page_counter underflow: %ld nr_pages=%lu\n", new, nr_pages)) zswap_stored_pages also becomes inconsistent in the same way. As suggested by Kanchana, increment zswap_stored_pages and charge zswap entries within zswap_store_page() when it succeeds. This way, zswap_entry_free() will decrement the counter and uncharge the entries when it failed to zswap the entire folio. While this could potentially be optimized by batching objcg charging and incrementing the counter, let's focus on fixing the bug this time and leave the optimization for later after some evaluation. After resolving the inconsistency, the warnings disappear. [42.hyeyoo@gmail.com: refactor zswap_store_page()]

13 Mar 2025, 21:14

Type Values Removed Values Added
CVSS v2 : unknown
v3 : unknown
v2 : unknown
v3 : 3.3
References () https://git.kernel.org/stable/c/63895d20d63b446f5049a963983489319c2ea3e2 - () https://git.kernel.org/stable/c/63895d20d63b446f5049a963983489319c2ea3e2 - Patch
References () https://git.kernel.org/stable/c/a3652f5552b20903315612da487a7be2b95394d5 - () https://git.kernel.org/stable/c/a3652f5552b20903315612da487a7be2b95394d5 - Patch
First Time Linux linux Kernel
Linux
Summary
  • (es) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm/zswap: se corrige una inconsistencia al fallar zswap_store_page(). El commit b7c0ccdfbafd ("mm: zswap: admite folios grandes en zswap_store()") omite el cobro de las entradas zswap cuando no se logra el cobro de todo el folio. Sin embargo, cuando se realizan cobros de algunas páginas base, pero no se logra el cobro de todo el folio, la operación de cobro se revierte. Al liberar las entradas zswap de esas páginas, zswap_entry_free() descarga las entradas zswap que no se habían cargado previamente, lo que provoca que el cobro de zswap se vuelva inconsistente. Esta inconsistencia activa dos advertencias con los siguientes pasos: # En una máquina con 64 GiB de RAM y 36 GiB de zswap $ stress-ng --bigheap 2 # esperar hasta que OOM-killer elimine stress-ng $ sudo reboot Las dos advertencias son: en mm/memcontrol.c:163, función obj_cgroup_release(): WARN_ON_ONCE(nr_bytes &amp; (PAGE_SIZE - 1)); en mm/page_counter.c:60, función page_counter_cancel(): if (WARN_ONCE(new &lt; 0, "page_counter underflow: %ld nr_pages=%lu\n", new, nr_pages)) zswap_stored_pages también se vuelve inconsistente de la misma manera. Como sugirió Kanchana, incremente zswap_stored_pages y cargue las entradas zswap dentro de zswap_store_page() cuando tenga éxito. De esta forma, zswap_entry_free() decrementará el contador y descargará las entradas cuando no pueda intercambiar todo el folio con zswap. Si bien esto podría optimizarse agrupando la carga de objcg e incrementando el contador, centrémonos en corregir el error esta vez y dejemos la optimización para más adelante, tras una evaluación. Tras resolver la inconsistencia, las advertencias desaparecen. [42.hyeyoo@gmail.com: refactorizar zswap_store_page()] Enlace: https://lkml.kernel.org/r/20250131082037.2426-1-42.hyeyoo@gmail.com
CPE cpe:2.3:o:linux:linux_kernel:6.14:rc2:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.14:rc1:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:6.14:rc3:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
CWE NVD-CWE-noinfo

12 Mar 2025, 10:15

Type Values Removed Values Added
New CVE

Information

Published : 2025-03-12 10:15

Updated : 2025-04-16 19:15


NVD link : CVE-2025-21860

Mitre link : CVE-2025-21860

CVE.ORG link : CVE-2025-21860


JSON object : View

Products Affected

linux

  • linux_kernel