CVE - CVE-2025-22030

CVE-ID
CVE-2025-22030	Learn more at National Vulnerability Database (NVD) • CVSS Severity Rating • Fix Information • Vulnerable Software Versions • SCAP Mappings • CPE Information
Description
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.
References
Note: References are provided for the convenience of the reader to help distinguish between vulnerabilities. The list is not intended to be complete.
MISC:https://git.kernel.org/stable/c/717d9c35deff6c33235693171bacbb03e9643fa4 URL:https://git.kernel.org/stable/c/717d9c35deff6c33235693171bacbb03e9643fa4 MISC:https://git.kernel.org/stable/c/747e3eec1d7d124ea90ed3d7b85369df8b4e36d2 URL:https://git.kernel.org/stable/c/747e3eec1d7d124ea90ed3d7b85369df8b4e36d2 MISC:https://git.kernel.org/stable/c/a8d18000e9d2d97aaf105f5f9b3b0e8a6fbf8b96 URL:https://git.kernel.org/stable/c/a8d18000e9d2d97aaf105f5f9b3b0e8a6fbf8b96 MISC:https://git.kernel.org/stable/c/c11bcbc0a517acf69282c8225059b2a8ac5fe628 URL:https://git.kernel.org/stable/c/c11bcbc0a517acf69282c8225059b2a8ac5fe628
Assigning CNA
kernel.org
Date Record Created
20241229	Disclaimer: The record creation date may reflect when the CVE ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.
Phase (Legacy)
Assigned (20241229)
Votes (Legacy)

Comments (Legacy)

Proposed (Legacy)
N/A
This is an record on the CVE List, which provides common identifiers for publicly known cybersecurity vulnerabilities.
Search CVE Using Keywords: You can also search by reference using the CVE Reference Maps.
For More Information: CVE Request Web Form (select "Other" from dropdown)