CVE-2025-22030

Source
https://nvd.nist.gov/vuln/detail/CVE-2025-22030
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2025-22030.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2025-22030
Related
Published
2025-04-16T15:15:55Z
Modified
2025-05-05T17:45:31.823005Z
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved:

mm: zswap: fix cryptofreeacomp() deadlock in zswapcpucomp_dead()

Currently, zswapcpucompdead() calls cryptofreeacomp() while holding the per-CPU acompctx mutex. cryptofreeacomp() then holds scomplock (through cryptoexitscompops_async()).

On the other hand, cryptoallocacompnode() holds the scomplock (through cryptoscompinittfm()), and then allocates memory. If the allocation results in reclaim, we may attempt to hold the per-CPU acompctx mutex.

The above dependencies can cause an ABBA deadlock. For example in the following scenario:

(1) Task A running on CPU #1: cryptoallocacompnode() Holds scomplock Enters reclaim Reads percpuptr(pool->acomp_ctx, 1)

(2) Task A is descheduled

(3) CPU #1 goes offline zswapcpucompdead(CPU #1) Holds percpuptr(pool->acompctx, 1)) Calls cryptofreeacomp() Waits for scomp_lock

(4) Task A running on CPU #2: Waits for percpuptr(pool->acomp_ctx, 1) // Read on CPU #1 DEADLOCK

Since there is no requirement to call cryptofreeacomp() with the per-CPU acompctx mutex held in zswapcpucompdead(), move it after the mutex is unlocked. Also move the acomprequestfree() and kfree() calls for consistency and to avoid any potential sublte locking dependencies in the future.

With this, only setting acompctx fields to NULL occurs with the mutex held. This is similar to how zswapcpucompprepare() 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

Affected packages

Debian:13 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.12.25-1

Affected versions

6.*

6.1.27-1
6.1.37-1
6.1.38-1
6.1.38-2~bpo11+1
6.1.38-2
6.1.38-3
6.1.38-4~bpo11+1
6.1.38-4
6.1.52-1
6.1.55-1~bpo11+1
6.1.55-1
6.1.64-1
6.1.66-1
6.1.67-1
6.1.69-1~bpo11+1
6.1.69-1
6.1.76-1~bpo11+1
6.1.76-1
6.1.82-1
6.1.85-1
6.1.90-1~bpo11+1
6.1.90-1
6.1.94-1~bpo11+1
6.1.94-1
6.1.98-1
6.1.99-1
6.1.106-1
6.1.106-2
6.1.106-3
6.1.112-1
6.1.115-1
6.1.119-1
6.1.123-1
6.1.124-1
6.1.128-1
6.1.129-1
6.1.133-1
6.1.135-1
6.3.1-1~exp1
6.3.2-1~exp1
6.3.4-1~exp1
6.3.5-1~exp1
6.3.7-1~bpo12+1
6.3.7-1
6.3.11-1
6.4~rc6-1~exp1
6.4~rc7-1~exp1
6.4.1-1~exp1
6.4.4-1~bpo12+1
6.4.4-1
6.4.4-2
6.4.4-3~bpo12+1
6.4.4-3
6.4.11-1
6.4.13-1
6.5~rc4-1~exp1
6.5~rc6-1~exp1
6.5~rc7-1~exp1
6.5.1-1~exp1
6.5.3-1~bpo12+1
6.5.3-1
6.5.6-1
6.5.8-1
6.5.10-1~bpo12+1
6.5.10-1
6.5.13-1
6.6.3-1~exp1
6.6.4-1~exp1
6.6.7-1~exp1
6.6.8-1
6.6.9-1
6.6.11-1
6.6.13-1~bpo12+1
6.6.13-1
6.6.15-1
6.6.15-2
6.7-1~exp1
6.7.1-1~exp1
6.7.4-1~exp1
6.7.7-1
6.7.9-1
6.7.9-2
6.7.12-1~bpo12+1
6.7.12-1
6.8.9-1
6.8.11-1
6.8.12-1~bpo12+1
6.8.12-1
6.9.2-1~exp1
6.9.7-1~bpo12+1
6.9.7-1
6.9.8-1
6.9.9-1
6.9.10-1~bpo12+1
6.9.10-1
6.9.11-1
6.9.12-1
6.10-1~exp1
6.10.1-1~exp1
6.10.3-1
6.10.4-1
6.10.6-1~bpo12+1
6.10.6-1
6.10.7-1
6.10.9-1
6.10.11-1~bpo12+1
6.10.11-1
6.10.12-1
6.11~rc4-1~exp1
6.11~rc5-1~exp1
6.11-1~exp1
6.11.2-1
6.11.4-1
6.11.5-1~bpo12+1
6.11.5-1
6.11.6-1
6.11.7-1
6.11.9-1
6.11.10-1~bpo12+1
6.11.10-1
6.12~rc6-1~exp1
6.12.3-1
6.12.5-1
6.12.6-1
6.12.8-1
6.12.9-1~bpo12+1
6.12.9-1
6.12.9-1+alpha
6.12.10-1
6.12.11-1
6.12.11-1+alpha
6.12.11-1+alpha.1
6.12.12-1~bpo12+1
6.12.12-1
6.12.13-1
6.12.15-1
6.12.16-1
6.12.17-1
6.12.19-1
6.12.20-1
6.12.21-1
6.12.22-1~bpo12+1
6.12.22-1

Ecosystem specific

{
    "urgency": "not yet assigned"
}