CVE-2026-74568
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic: Fix race between LPI release and re-registration
Fix a potential race between decrementing an LPI's reference count and evicting that structure from the LPI xarray.
LPI structures are maintained in the VGIC LPI xarray (dist->lpi_xa). When the reference count of an LPI structure drops to zero, vgic_release_lpi_locked() removes the structure from the xarray and frees it under the xarray lock.
However, the release of an LPI can race with a concurrent LPI re-registration with the same INTID via vgic_add_lpi() on another CPU, since the reference count drop and the xarray eviction are not performed in a single atomic step.
Leer descripción completaMostrar menos
This can happen e.g. if the guest issues a DISCARD while the LPI is still referenced from a vCPU's active-pending list (ap_list), and the same INTID is re-mapped via MAPTI.
Particularly, vgic_release_lpi_locked() is called from two distinct paths: direct release via vgic_put_irq(), and deferred release via vgic_release_deleted_lpis(). During direct release, the issue can result in deleting a newly registered LPI from the xarray:
During the deferred release path, the old IRQ can be leaked:
To fix the direct release path, move the reference count drop inside the xarray lock, making sure that vgic_add_lpi() never encounters the to-be-released LPI.
In the deferred release path, the refcount drop must happen under a raw spinlock, so the xarray lock cannot be grabbed, and the same solution does not work. Instead, update vgic_add_lpi(), so that if it evicts an LPI from the xarray, it takes on the responsibility of freeing it. Consequently, an LPI may now be freed concurrently after a deferred release drops the refcount, so accessing the pending_release field is no longer safe from use-after-free. Delete all uses of the flag, and update vgic_release_deleted_lpis() to identify orphaned LPIs purely based on their refcount.
Detalles técnicos trazas, registros y código del informe original
CPU0 (Releasing LPI) CPU1 (Adding new LPI)
==================== =====================
vgic_put_irq()
__vgic_put_irq()
refcount_dec_and_test()
vgic_add_lpi()
xa_lock_irqsave()
old_irq = xa_load(.., intid)
vgic_try_get_irq_ref(old_irq) == false
new IRQ inserted --> __xa_store(.., intid, ..)
xa_unlock_irqrestore()
xa_lock_irqsave();
vgic_release_lpi_locked()
__xa_erase(.., irq->intid) <-- BUG: new IRQ is erased
kfree_rcu(old_irq)
CPU0 (Releasing LPI) CPU1 (Adding new LPI)
==================== =====================
vgic_put_irq_norelease()
__vgic_put_irq()
refcount_dec_and_test()
irq->pending_release = true
vgic_add_lpi()
xa_lock_irqsave()
old_irq = xa_load(.., intid)
vgic_try_get_irq_ref(oldirq) == false
BUG: old IRQ overwritten --> __xa_store(.., intid, ..)
xa_unlock_irqrestore()
vgic_release_deleted_lpis()
xa_lock_irqsave()
xa_for_each() { .. } <-- old IRQ with pending_release = true
is gone, so it cannot be releasedCVSS
- Versión: 3.1
- Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
- Puntuación base: 9.3
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días: 0.18%
- Percentil entre todas las CVEs puntuadas: 7
- Fecha de la puntuación: 6/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
🎯 Técnicas ATT&CK
Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.
- Explotación
T1068Exploitation for Privilege Escalationprivilege escalation85 %
Vulnerabilidad de escalada de privilegios en kernel Linux (AV:L, PR:N) que permite DoS del sistema (C:H/I:H/A:H) mediante race condition en VGIC LPI, explotable localmente sin interacción del usuario.
Inferido por nuestro agente de análisis a partir de la descripción oficial, el vector CVSS y la CWE, y comprobado por un supervisor. Puede contener errores.
🛡️ Mitigaciones ATT&CK que cubren estas técnicas
Tecnologías afectadas (1)
⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.
Referencias
JSON original (NVD)
Mostrar
{
"id": "CVE-2026-74568",
"cveTags": [],
"metrics": {
"cvssMetricV31": [
{
"type": "Secondary",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"cvssData": {
"scope": "CHANGED",
"version": "3.1",
"baseScore": 9.3,
"attackVector": "LOCAL",
"baseSeverity": "CRITICAL",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"integrityImpact": "HIGH",
"userInteraction": "NONE",
"attackComplexity": "LOW",
"availabilityImpact": "HIGH",
"privilegesRequired": "NONE",
"confidentialityImpact": "HIGH"
},
"impactScore": 6,
"exploitabilityScore": 2.5
}
]
},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "3a08a6ca7c373198c84e2a8c025c395ee966ff8a",
"lessThan": "292e80a159aa88635bf668a7212cfdf526b8bd52",
"versionType": "git"
},
{
"status": "affected",
"version": "3a08a6ca7c373198c84e2a8c025c395ee966ff8a",
"lessThan": "cbfe2b24a1ea9de35032dbdd100fdc700f5be92d",
"versionType": "git"
}
],
"programFiles": [
"arch/arm64/kvm/vgic/vgic-its.c",
"arch/arm64/kvm/vgic/vgic.c",
"include/kvm/arm_vgic.h"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "6.17"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "6.17",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "7.1.8",
"versionType": "semver",
"lessThanOrEqual": "7.1.*"
},
{
"status": "unaffected",
"version": "7.2",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"arch/arm64/kvm/vgic/vgic-its.c",
"arch/arm64/kvm/vgic/vgic.c",
"include/kvm/arm_vgic.h"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-08-15T13:18:02.370",
"references": [
{
"url": "https://git.kernel.org/stable/c/292e80a159aa88635bf668a7212cfdf526b8bd52",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/cbfe2b24a1ea9de35032dbdd100fdc700f5be92d",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Received",
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: vgic: Fix race between LPI release and re-registration\n\nFix a potential race between decrementing an LPI's reference count and\nevicting that structure from the LPI xarray.\n\nLPI structures are maintained in the VGIC LPI xarray (dist->lpi_xa).\nWhen the reference count of an LPI structure drops to zero,\nvgic_release_lpi_locked() removes the structure from the xarray and\nfrees it under the xarray lock.\n\nHowever, the release of an LPI can race with a concurrent LPI\nre-registration with the same INTID via vgic_add_lpi() on another CPU,\nsince the reference count drop and the xarray eviction are not performed\nin a single atomic step. This can happen e.g. if the guest issues a\nDISCARD while the LPI is still referenced from a vCPU's active-pending\nlist (ap_list), and the same INTID is re-mapped via MAPTI.\n\nParticularly, vgic_release_lpi_locked() is called from two distinct\npaths: direct release via vgic_put_irq(), and deferred release via\nvgic_release_deleted_lpis(). During direct release, the issue can result\nin deleting a newly registered LPI from the xarray:\n\n CPU0 (Releasing LPI) CPU1 (Adding new LPI)\n ==================== =====================\n vgic_put_irq()\n __vgic_put_irq()\n refcount_dec_and_test()\n vgic_add_lpi()\n xa_lock_irqsave()\n old_irq = xa_load(.., intid)\n vgic_try_get_irq_ref(old_irq) == false\n new IRQ inserted --> __xa_store(.., intid, ..)\n xa_unlock_irqrestore()\n xa_lock_irqsave();\n vgic_release_lpi_locked()\n __xa_erase(.., irq->intid) <-- BUG: new IRQ is erased\n kfree_rcu(old_irq)\n\nDuring the deferred release path, the old IRQ can be leaked:\n\n CPU0 (Releasing LPI) CPU1 (Adding new LPI)\n ==================== =====================\n vgic_put_irq_norelease()\n __vgic_put_irq()\n refcount_dec_and_test()\n irq->pending_release = true\n vgic_add_lpi()\n xa_lock_irqsave()\n old_irq = xa_load(.., intid)\n vgic_try_get_irq_ref(oldirq) == false\n BUG: old IRQ overwritten --> __xa_store(.., intid, ..)\n xa_unlock_irqrestore()\n\n vgic_release_deleted_lpis()\n xa_lock_irqsave()\n xa_for_each() { .. } <-- old IRQ with pending_release = true\n is gone, so it cannot be released\n\nTo fix the direct release path, move the reference count drop inside\nthe xarray lock, making sure that vgic_add_lpi() never encounters the\nto-be-released LPI.\n\nIn the deferred release path, the refcount drop must happen under a raw\nspinlock, so the xarray lock cannot be grabbed, and the same solution\ndoes not work. Instead, update vgic_add_lpi(), so that if it evicts\nan LPI from the xarray, it takes on the responsibility of freeing it.\nConsequently, an LPI may now be freed concurrently after a deferred\nrelease drops the refcount, so accessing the pending_release field is no\nlonger safe from use-after-free. Delete all uses of the flag, and update\nvgic_release_deleted_lpis() to identify orphaned LPIs purely based on\ntheir refcount."
}
],
"lastModified": "2026-08-17T06:19:55.053",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}