U.S. flag   An official website of the United States government
Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Https

Secure .gov websites use HTTPS
A lock (Dot gov) or https:// means you've safely connected to the .gov website. Share sensitive information only on official, secure websites.

Vulnerability Change Records for CVE-2026-74568

Change History

New CVE Received from kernel.org 8/15/2026 9:18:02 AM

Action Type Old Value New Value
Added 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'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.
Added Reference

                  
                
              
https://git.kernel.org/stable/c/292e80a159aa88635bf668a7212cfdf526b8bd52
Added Reference

                  
                
              
https://git.kernel.org/stable/c/cbfe2b24a1ea9de35032dbdd100fdc700f5be92d
Added Affected

                  
                
              
[{"vendor":"Linux","product":"Linux","defaultStatus":"unaffected","programFiles":["arch/arm64/kvm/vgic/vgic-its.c","arch/arm64/kvm/vgic/vgic.c","include/kvm/arm_vgic.h"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","versions":[{"version":"3a08a6ca7c373198c84e2a8c025c395ee966ff8a","lessThan":"292e80a159aa88635bf668a7212cfdf526b8bd52","versionType":"git","status":"affected"},{"version":"3a08a6ca7c373198c84e2a8c025c395ee966ff8a","lessThan":"cbfe2b24a1ea9de35032dbdd100fdc700f5be92d","versionType":"git","status":"affected"}]},{"vendor":"Linux","product":"Linux","defaultStatus":"affected","programFiles":["arch/arm64/kvm/vgic/vgic-its.c","arch/arm64/kvm/vgic/vgic.c","include/kvm/arm_vgic.h"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","versions":[{"version":"6.17","status":"affected"},{"version":"0","lessThan":"6.17","versionType":"semver","status":"unaffected"},{"version":"7.1.8","lessThanOrEqual":"7.1.*","versionType":"semver","status":"unaffected"},{"version":"7.2-rc6","lessThanOrEqual":"*","versionType":"original_commit_for_fix","status":"unaffected"}]}]