CVE-2026-74568: KVM: arm64: vgic: Fix race between LPI release and re-registration

Is it exploited?

Not on CISA's list. CISA has not added it to the Known Exploited Vulnerabilities catalog as of 28 Oct 2026. If CISA adds it, this page shows it as known exploited.

How likely is exploitation in the next 30 days?

0.2%

EPSS score, percentile 8.4 of all scored records. A probability estimated by FIRST, not a report of exploitation.

How severe?

9.3 Critical

CVSS v3.1 base score, given by the CNA

What should I do?

CISA has set no required action, because the vulnerability is not in KEV.

The CVE record links no vendor advisory, patch or mitigation.

Which versions are affected?

Affected

• 6.17

Unaffected before 6.17; 6.18.57; 7.1.8; 7.2

Versions by product

Source: CISA KEV 2026.10.28, as of 28 Oct 2026; FIRST EPSS, as of 29 Oct 2026; CVE List, as of 29 Oct 2026. About the data.

What to do

Advisories and patches

The CVE record links no vendor advisory, patch or mitigation.

This summary is based on the CVE record as of 29 Oct 2026. Check the vendor's advisory before you act: affected versions and fixes can change.

Affected products and versions

As listed in the CVE record.

Versions not listed are: unaffected.

Versions not listed are: affected.

Versions the record lists as unaffected: 6.18.57, 7.1.8, 7.2.

Source: CVE List, as of 29 Oct 2026. About the data.

About this vulnerability

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…

Summary: CVE record, as of 29 Oct 2026.

• CISA has not added CVE-2026-74568 to its Known Exploited Vulnerabilities (KEV) catalog, as of 28 Oct 2026.
• The CVE record was published on 15 Aug 2026.
• The CVE record carries a CVSS v3.1 base score of 9.3 (Critical), given by its CNA.
• FIRST's EPSS model puts the probability of exploitation in the next 30 days at 0.2% (percentile 8.4), as of 29 Oct 2026. EPSS is a statistical estimate, not a report of exploitation.
• CISA's SSVC assessment in the CVE record: exploitation none, automatable no, technical impact total.

Source: CISA KEV 2026.10.28, as of 28 Oct 2026; CVE List, as of 29 Oct 2026; FIRST EPSS, as of 29 Oct 2026. About the data.

Description

KVM: arm64: vgic: Fix race between LPI release and re-registration

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

Source: CVE List, as of 29 Oct 2026. About the data.

Timeline

Known exploited Linux vulnerabilities

• CVE-2026-46300: Linux Kernel Missing Initialization of a Variable Vulnerability (added 28 Oct 2026)
• CVE-2025-39682: Linux Kernel Improper Check for Unusual or Exceptional Conditions Vulnerability (added 18 Sep 2026)
• CVE-2025-39964: Linux Kernel Race Condition Vulnerability (added 18 Sep 2026)
• CVE-2026-53266: Linux Kernel Out-of-Bounds Write Vulnerability (added 18 Sep 2026)
• CVE-2026-53362: Linux Kernel Unspecified Vulnerability (added 27 Aug 2026)