In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
KVM: arm64: vgic: Fix race between LPI release and re-registration<\/p>\n
Fix a potential race between decrementing an LPI’s reference count and
\nevicting that structure from the LPI xarray.<\/p>\n
LPI 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.<\/p>\n
However, 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.<\/p>\n
Particularly, 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:<\/p>\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) 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()<\/p>\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<\/p>\n
To 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.<\/p>\n
In 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.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
KVM: arm64: vgic: Fix race between LPI release and re-registration<\/p>\n
Fix a potential race between decrementing an LPI’s reference co<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-7586","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/7586","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=7586"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=7586"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=7586"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}