---
cve: "CVE-2026-74568"
severity: "CRITICAL"
cvss: 9.3
epss: "12%"
vendor: "Linux"
kev: false
exploited: false
published: "2026-08-15 13:18:02"
tags: [cve, security, critical]
source: tsecurity.de CVE-Dossier
exported: "2026-08-31T20:03:01+02:00"
---

# CVE-2026-74568

> 9.3 CRITICAL

## Beschreibung

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. 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:

  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)   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() { .. }

## CVSS-Vektor

```
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
```

| Metrik | Wert | Bewertung |
|---|---|---|
| AV Angriffsvektor | Lokal | good |
| AC Komplexität | Gering | bad |
| PR Privilegien | Keine | bad |
| UI Interaktion | Keine | bad |
| S Scope | Verändert | bad |
| C Vertraulichkeit | Hoch | bad |
| I Integrität | Hoch | bad |
| A Verfügbarkeit | Hoch | bad |

## Patch verfügbar (OSV)

- Kernel ≥ 7.1.8

## Referenzen

- <https://git.kernel.org/stable/c/292e80a159aa88635bf668a7212cfdf526b8bd52>
- <https://git.kernel.org/stable/c/cbfe2b24a1ea9de35032dbdd100fdc700f5be92d>

---
_Exportiert aus dem [tsecurity.de CVE-Dossier](https://tsecurity.de/cve?cve=CVE-2026-74568) · Datenquellen: EUVD (ENISA), NVD, OSV, CISA KEV, FIRST EPSS, Exploit-DB, BSI BITS_
