CVE-2024-26832

What it actually does

Missing folio unlock and put in zswap_writeback_entry() after detecting a recycled swap entry leaves a locked and referenced folio stranded in memory.

Why it matters to the business

Linux systems using zswap may experience gradual memory resource exhaustion under rare race conditions, potentially leading to performance degradation or out-of-memory situations on affected kernels.

How an attack unfolds

An attacker with local access triggers the specific swap cache race in zswap writeback; the kernel path fails to release the folio, accumulating stranded memory over repeated occurrences. No named threat actors are known to exploit this.

How to fix it

Upgrade to a fixed kernel version such as 6.1.80 or apply the commit 14f1992430ef9e647b02aa8ca12c5bcb9a1dffea (and equivalents in other stable branches). Reboot after updating the kernel.

How to confirm the fix worked

Confirm the running kernel version is at or above the listed fixed releases; inspect zswap code for the added folio unlock/put calls in the writeback race path.

Typical attack path

1. Obtain local access to a system running an affected Linux kernel with zswap enabled
2. Induce swap activity that hits the writeback path concurrently with swap entry invalidation
3. Trigger the race condition repeatedly to strand multiple folios

How to detect it

Review kernel logs for zswap-related warnings or excessive swap cache growth; examine memory statistics for orphaned folios in the writeback path.

What your security team should do

• Prioritize kernel updates on systems with zswap enabled
• Monitor memory usage trends for unexpected folio or swap cache growth
• Apply the fix during the next maintenance window if not already done