CVE-2025-22030 in Linux
Summary
by MITRE • 04/16/2025
In the Linux kernel, the following vulnerability has been resolved:
mm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead()
Currently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holding the per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp_lock (through crypto_exit_scomp_ops_async()).
On the other hand, crypto_alloc_acomp_node() holds the scomp_lock (through crypto_scomp_init_tfm()), and then allocates memory. If the allocation results in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex.
The above dependencies can cause an ABBA deadlock. For example in the following scenario:
(1) Task A running on CPU #1: crypto_alloc_acomp_node() Holds scomp_lock Enters reclaim Reads per_cpu_ptr(pool->acomp_ctx, 1)
(2) Task A is descheduled
(3) CPU #1 goes offline zswap_cpu_comp_dead(CPU #1) Holds per_cpu_ptr(pool->acomp_ctx, 1)) Calls crypto_free_acomp() Waits for scomp_lock
(4) Task A running on CPU #2: Waits for per_cpu_ptr(pool->acomp_ctx, 1) // Read on CPU #1 DEADLOCK
Since there is no requirement to call crypto_free_acomp() with the per-CPU acomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex is unlocked. Also move the acomp_request_free() and kfree() calls for consistency and to avoid any potential sublte locking dependencies in the future.
With this, only setting acomp_ctx fields to NULL occurs with the mutex held. This is similar to how zswap_cpu_comp_prepare() only initializes acomp_ctx fields with the mutex held, after performing all allocations before holding the mutex.
Opportunistically, move the NULL check on acomp_ctx so that it takes place before the mutex dereference.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 02/15/2026
The vulnerability described in CVE-2025-22030 affects the Linux kernel's zswap subsystem, which is designed to compress swap pages in memory to improve system performance. This particular flaw manifests as an ABBA deadlock condition that can occur during CPU hot-unplug operations when the kernel attempts to clean up compression contexts. The issue resides in the zswap_cpu_comp_dead() function where improper locking order creates a circular dependency between the per-CPU acomp_ctx mutex and the scomp_lock, leading to system hangs that can severely impact system stability and availability.
The technical root cause of this vulnerability stems from the improper acquisition of locks in the zswap_cpu_comp_dead() function. When a CPU goes offline, this function attempts to free compression contexts while holding the per-CPU acomp_ctx mutex. However, the crypto_free_acomp() function internally attempts to acquire the scomp_lock, which creates a deadlock scenario when combined with the lock ordering that occurs during memory allocation in crypto_alloc_acomp_node(). This creates a classic ABBA deadlock pattern where Task A holds scomp_lock and waits for per-CPU context mutex, while the zswap_cpu_comp_dead() function holds the per-CPU mutex and waits for scomp_lock, resulting in a complete system hang.
The operational impact of this vulnerability is significant as it can cause system-wide deadlocks during normal CPU hot-unplug operations, which are common in modern server environments where dynamic CPU management is utilized for power optimization and workload balancing. The vulnerability affects systems using zswap functionality and can lead to complete system freezes, requiring manual intervention or system reboot to recover. This type of deadlock directly impacts the reliability and availability of Linux-based systems, particularly in server and cloud environments where dynamic resource management is critical.
The fix implemented addresses the core locking issue by reordering the operations within zswap_cpu_comp_dead() to release the per-CPU acomp_ctx mutex before calling crypto_free_acomp(), thereby breaking the circular dependency. This solution aligns with the principle of maintaining consistent lock ordering and follows best practices for avoiding deadlock conditions in kernel code. The change also moves the NULL check for acomp_ctx to occur before the mutex dereference, preventing potential race conditions and ensuring proper synchronization. This remediation follows established kernel development practices and aligns with the ATT&CK framework's system and information integrity tactics, specifically addressing the risk of system hang and denial of service through improper locking mechanisms. The fix also references CWE-362, which describes the weakness of concurrent access to shared resources without proper synchronization, and CWE-121, which addresses stack-based buffer overflow conditions that can result from improper lock ordering. The solution maintains the same functional behavior while eliminating the deadlock condition through careful lock ordering and proper resource cleanup sequencing.