FKIE_CVE-2025-22030
Vulnerability from fkie_nvd - Published: 2025-04-16 15:15 - Updated: 2026-06-17 08:44
Severity
Summary
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
Impacted products
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.13 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"mm/zswap.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "747e3eec1d7d124ea90ed3d7b85369df8b4e36d2",
"status": "affected",
"version": "8d29ff5d50304daa41dc3cfdda4a9d1e46cf5be1",
"versionType": "git"
},
{
"lessThan": "a8d18000e9d2d97aaf105f5f9b3b0e8a6fbf8b96",
"status": "affected",
"version": "12dcb0ef540629a281533f9dedc1b6b8e14cfb65",
"versionType": "git"
},
{
"lessThan": "717d9c35deff6c33235693171bacbb03e9643fa4",
"status": "affected",
"version": "12dcb0ef540629a281533f9dedc1b6b8e14cfb65",
"versionType": "git"
},
{
"lessThan": "c11bcbc0a517acf69282c8225059b2a8ac5fe628",
"status": "affected",
"version": "12dcb0ef540629a281533f9dedc1b6b8e14cfb65",
"versionType": "git"
},
{
"lessThan": "6.12.23",
"status": "affected",
"version": "6.12.12",
"versionType": "semver"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"mm/zswap.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.13"
},
{
"lessThan": "6.13",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.23",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.14.*",
"status": "unaffected",
"version": "6.14.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.15",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C007FC9C-EF72-4E8D-B8AF-1F5CEBB036E0",
"versionEndExcluding": "6.12.23",
"versionStartIncluding": "6.12.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A1ED3A9A-88AD-47D5-B428-93C7630E46F8",
"versionEndExcluding": "6.13.11",
"versionStartIncluding": "6.13.1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "FADAE5D8-4808-442C-B218-77B2CE8780A0",
"versionEndExcluding": "6.14.2",
"versionStartIncluding": "6.14",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.13:-:*:*:*:*:*:*",
"matchCriteriaId": "5A3F9505-6B98-4269-8B81-127E55A1BF00",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead()\n\nCurrently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holding\nthe per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp_lock\n(through crypto_exit_scomp_ops_async()).\n\nOn the other hand, crypto_alloc_acomp_node() holds the scomp_lock (through\ncrypto_scomp_init_tfm()), and then allocates memory. If the allocation\nresults in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex.\n\nThe above dependencies can cause an ABBA deadlock. For example in the\nfollowing scenario:\n\n(1) Task A running on CPU #1:\n crypto_alloc_acomp_node()\n Holds scomp_lock\n Enters reclaim\n Reads per_cpu_ptr(pool-\u003eacomp_ctx, 1)\n\n(2) Task A is descheduled\n\n(3) CPU #1 goes offline\n zswap_cpu_comp_dead(CPU #1)\n Holds per_cpu_ptr(pool-\u003eacomp_ctx, 1))\n Calls crypto_free_acomp()\n Waits for scomp_lock\n\n(4) Task A running on CPU #2:\n Waits for per_cpu_ptr(pool-\u003eacomp_ctx, 1) // Read on CPU #1\n DEADLOCK\n\nSince there is no requirement to call crypto_free_acomp() with the per-CPU\nacomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex is\nunlocked. Also move the acomp_request_free() and kfree() calls for\nconsistency and to avoid any potential sublte locking dependencies in the\nfuture.\n\nWith this, only setting acomp_ctx fields to NULL occurs with the mutex\nheld. This is similar to how zswap_cpu_comp_prepare() only initializes\nacomp_ctx fields with the mutex held, after performing all allocations\nbefore holding the mutex.\n\nOpportunistically, move the NULL check on acomp_ctx so that it takes place\nbefore the mutex dereference."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: zswap: correcci\u00f3n del bloqueo de crypto_free_acomp() en zswap_cpu_comp_dead(). Actualmente, zswap_cpu_comp_dead() llama a crypto_free_acomp() mientras mantiene el mutex acomp_ctx por CPU. A continuaci\u00f3n, crypto_free_acomp() mantiene scomp_lock (mediante crypto_exit_scomp_ops_async()). Por otro lado, crypto_alloc_acomp_node() mantiene scomp_lock (mediante crypto_scomp_init_tfm()) y luego asigna memoria. Si la asignaci\u00f3n resulta en una recuperaci\u00f3n, podemos intentar mantener el mutex acomp_ctx por CPU. Las dependencias anteriores pueden causar un bloqueo de ABBA. Por ejemplo, en el siguiente escenario: (1) Tarea A ejecut\u00e1ndose en la CPU n.\u00ba 1: crypto_alloc_acomp_node() Retiene scomp_lock Ingresa a recuperaci\u00f3n Lee per_cpu_ptr(pool-\u0026gt;acomp_ctx, 1) (2) La tarea A se desprograma (3) La CPU n.\u00ba 1 se desconecta zswap_cpu_comp_dead(CPU n.\u00ba 1) Retiene per_cpu_ptr(pool-\u0026gt;acomp_ctx, 1)) Llama a crypto_free_acomp() Espera a scomp_lock (4) Tarea A ejecut\u00e1ndose en la CPU n.\u00ba 2: Espera a per_cpu_ptr(pool-\u0026gt;acomp_ctx, 1) // Lee en la CPU n.\u00ba 1 BLOQUEO INTERMEDIO Dado que no es necesario llamar a crypto_free_acomp() con el mutex acomp_ctx por CPU retenido en zswap_cpu_comp_dead(), mu\u00e9valo despu\u00e9s de que se desbloquee el mutex. Tambi\u00e9n se desplazan las llamadas acomp_request_free() y kfree() para mantener la coherencia y evitar posibles dependencias de bloqueo sutil en el futuro. Con esto, solo se establece el valor NULL de los campos acomp_ctx con el mutex retenido. Esto es similar a c\u00f3mo zswap_cpu_comp_prepare() solo inicializa los campos acomp_ctx con el mutex retenido, despu\u00e9s de realizar todas las asignaciones antes de retener el mutex. Oportunistamente, se desplaza la comprobaci\u00f3n de valores NULL en acomp_ctx para que se realice antes de la desreferencia del mutex."
}
],
"id": "CVE-2025-22030",
"lastModified": "2026-06-17T08:44:53.033",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2025-04-16T15:15:55.607",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/717d9c35deff6c33235693171bacbb03e9643fa4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/747e3eec1d7d124ea90ed3d7b85369df8b4e36d2"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a8d18000e9d2d97aaf105f5f9b3b0e8a6fbf8b96"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c11bcbc0a517acf69282c8225059b2a8ac5fe628"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-667"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
Loading…
Loading…
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.