CVE-2025-21860 in Linux
Summary
by MITRE • 03/12/2025
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.
[[email protected]: refactor zswap_store_page()]
Link: https://lkml.kernel.org/r/[email protected]
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 12/14/2025
The vulnerability described in CVE-2025-21860 affects the Linux kernel's memory management subsystem, specifically within the zswap implementation that provides compressed swap storage for memory pages. This issue manifests as an inconsistency in the charging mechanism when zswap operations fail to store entire folios, creating a scenario where memory accounting becomes corrupted and triggers system warnings. The problem stems from the improper handling of zswap entries during partial failures, where some base pages may be successfully compressed and stored while others fail, leading to an inconsistent state in the memory control subsystem.
The technical flaw occurs in the mm/zswap subsystem where the zswap_store_page() function fails to maintain consistent accounting when processing large folios that exceed the capacity of zswap storage. When a folio fails to be fully compressed and stored, the system attempts to roll back the operation by freeing previously allocated zswap entries. However, the zswap_entry_free() function incorrectly uncharges entries that were never charged, creating a discrepancy in the memory accounting system. This inconsistency specifically impacts the memory control group (objcg) charging mechanism and page counter operations, as evidenced by the two distinct warning messages that appear during system operation.
The operational impact of this vulnerability extends beyond simple warning messages, as it creates potential memory accounting inconsistencies that could lead to system instability and incorrect resource management. The warnings indicate fundamental problems in the memory subsystem where page counter values become negative and memory control group accounting shows invalid byte values, both of which represent serious violations of memory management principles. When systems with substantial memory configurations and active zswap usage encounter this condition, particularly under stress scenarios like those generated by stress-ng tools, the system may experience unexpected behavior and potential memory allocation failures.
The resolution for this vulnerability involves modifying the zswap_store_page() function to ensure that zswap_stored_pages counter and zswap entries are properly incremented and charged only when the operation succeeds completely. This approach prevents the inconsistent state that occurs when partial failures trigger incorrect uncharging operations. The fix aligns with established memory management practices by ensuring that all accounting operations maintain consistency and that resource allocation is properly tracked throughout the entire operation lifecycle. The solution addresses the root cause rather than merely masking symptoms, making it consistent with best practices for kernel memory management and security hardening.
This vulnerability demonstrates the importance of maintaining consistency in kernel memory accounting systems, particularly when dealing with complex operations that involve multiple resource types and partial failure conditions. The issue relates to CWE-128, which covers "Wrap-around Error," and CWE-129, which addresses "Out-of-bounds Access," both of which can manifest in memory accounting inconsistencies. From an ATT&CK perspective, this vulnerability could potentially be leveraged to create resource exhaustion conditions or memory corruption scenarios that might affect system stability and availability, though it does not directly enable privilege escalation or direct code execution. The fix ensures proper resource management and prevents the accumulation of inconsistent accounting states that could be exploited or lead to system instability under stress conditions.