CVE-2025-21860 is a vulnerability identified in the Linux kernel's memory management subsystem, specifically within the zswap feature. Zswap is a compressed cache for swap pages that aims to improve system performance by reducing I/O to slower swap devices. The vulnerability arises from an inconsistency in how zswap handles charging and accounting of memory pages when storing large folios (groups of contiguous pages) fails partially. The patch commit b7c0ccdfbafd introduced support for large folios in zswap_store(), but it skipped charging zswap entries when the entire folio could not be successfully stored. However, if some base pages were zswapped but the entire folio storage failed, the operation would roll back, and zswap_entry_free() would uncharge entries that were never charged, leading to inconsistent accounting. This inconsistency manifests as kernel warnings related to memory control groups and page counters, specifically WARN_ON_ONCE triggers indicating page counter underflows and object cgroup release inconsistencies. The issue can be reproduced under heavy memory pressure (e.g., using stress-ng with a large heap) followed by an out-of-memory (OOM) kill and reboot. The root cause is that zswap_stored_pages and charging counters become inconsistent, potentially leading to incorrect memory accounting. The fix involves incrementing zswap_stored_pages and charging zswap entries immediately upon successful storage of pages in zswap_store_page(), ensuring that any rollback correctly decrements these counters and uncharges entries. While the fix addresses the correctness of accounting, it does not optimize the charging process, which may be improved later. No known exploits are reported in the wild, and no CVSS score has been assigned yet. This vulnerability is primarily a kernel memory management bug that can cause warnings and inconsistent memory accounting but does not directly indicate a memory corruption or privilege escalation vector.

For European organizations, the impact of CVE-2025-21860 is primarily related to system stability and reliability rather than direct compromise or data breach. Systems running affected Linux kernel versions with zswap enabled and under heavy memory pressure may experience kernel warnings, potential memory accounting inconsistencies, and possibly degraded performance or unexpected behavior in memory management. This could lead to increased risk of system crashes or OOM conditions if memory is not properly accounted for, affecting critical infrastructure, servers, or cloud environments. Organizations relying on Linux servers for critical applications, especially those with large memory footprints or high memory utilization, may see increased operational risk and troubleshooting complexity. However, since no direct exploitation or privilege escalation is known, the confidentiality and integrity of data are not immediately threatened. The availability impact is medium, as improper memory accounting could lead to instability or unexpected OOM kills, potentially disrupting services. European entities with large-scale Linux deployments, including cloud providers, hosting companies, and enterprises running containerized or virtualized workloads, should be aware of this issue. The vulnerability underscores the importance of applying kernel updates promptly to maintain system reliability.

1. Apply the official Linux kernel patches that fix CVE-2025-21860 as soon as they become available from trusted sources or Linux distributions. 2. Monitor kernel logs for WARN_ON_ONCE messages related to memory control groups and page counter underflows, which may indicate the presence of this issue. 3. For systems with heavy memory usage and zswap enabled, consider temporarily disabling zswap if patching is delayed and system stability issues are observed, though this may impact performance. 4. Implement proactive memory usage monitoring and alerting to detect abnormal memory pressure conditions that could trigger the vulnerability. 5. Test kernel updates in staging environments that simulate production memory loads to verify stability before wide deployment. 6. Maintain up-to-date backups and recovery plans to mitigate potential availability impacts from unexpected OOM kills or system reboots. 7. Engage with Linux distribution vendors for timely security advisories and patches related to this vulnerability. 8. Avoid running untrusted or unverified kernel modules or patches that could exacerbate memory management issues. These steps go beyond generic advice by focusing on monitoring specific kernel warnings, considering temporary zswap disablement, and emphasizing staged testing under memory stress.