{
  "cveId": "CVE-2026-74568",
  "url": "https://patchblox.com/security/cve/CVE-2026-74568",
  "summary": "CVE-2026-74568 is fixed in linux on 1 platform by DEBIAN-CVE-2026-74568 (version 7.1.8-1), released August 16, 2026. It is not reported as exploited. Patch Radar priority: Urgent.",
  "title": "linux: In the Linux kernel, the following vulnerability has been resolved:  KVM: arm64: vgic: Fix race between LPI release a...",
  "description": "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\u0027s reference count and evicting that structure from the LPI xarray.  LPI structures are maintained in the VGIC LPI xarray (dist-\u003Elpi_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\u0027s 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 --\u003E  __xa_store(.., intid, ..)                                               xa_unlock_irqrestore()   xa_lock_irqsave();   vgic_release_lpi_locked()       __xa_erase(.., irq-\u003Eintid)   \u003C-- BUG: new IRQ is erased       kfree_rcu(old_irq)  During the deferred release path, the old IRQ can be leaked:    CPU0 (Releasing LPI)                    CPU1 (Adding new LPI)   ====================                    =====================   vgic_put_irq_norelease()       __vgic_put_irq()           refcount_dec_and_test()       irq-\u003Epending_release = true                                           vgic_add_lpi()                                               xa_lock_irqsave()                                               old_irq = xa_load(.., intid)                                               vgic_try_get_irq_ref(oldirq) == false                  BUG: old IRQ overwritten --\u003E __xa_store(.., intid, ..)                                               xa_unlock_irqrestore()    vgic_release_deleted_lpis()       xa_lock_irqsave()       xa_for_each() { .. } \u003C-- old IRQ with pending_release = true                                is gone, so it cannot be released  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.",
  "published": "2026-08-15T13:18:02Z",
  "severity": "critical",
  "cvss": 9.3,
  "cvssVector": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
  "epss": 0.00188,
  "epssPercentile": 0.08475,
  "priority": "Urgent",
  "priorityTier": 2,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "7.1.8-1",
      "fix": "DEBIAN-CVE-2026-74568",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2026-74568",
      "released": "2026-08-16T22:48:20Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-09T01:18:40Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}