GPU VulnDB

Database/Kernel, userspace & hypervisor

KVM arm64 vgic-v3: unreferenced LPI iteration lets a freed vgic_irq be dereferenced while saving pending tables

CVSS 8.8CVE-2026-89913Kernel, userspace & hypervisorcurated

Impact

vgic_v3_save_pending_tables() walked dist->lpi_xa with xa_for_each() and dereferenced each struct vgic_irq without taking a reference, relying on RCU coverage that only spans the individual lookup. A guest that drives ITS DISCARD while an irqfd cached injection holds the last transient reference can cause the LPI to be erased and kfree_rcu()'d while the save path still holds the pointer, giving a use-after-free in host kernel context across a guest memory access. On Arm GPU hosts (Grace-class nodes running KVM guests), this is a guest-triggerable host memory corruption primitive, which on a multi-tenant node means one VM potentially reaching host state shared with every other VM on the box. The fix re-fetches each LPI via vgic_get_irq() and drops the reference on all paths.

Who can reach it

Local, from inside a guest VM on an arm64 KVM host: a guest with a virtual ITS that can issue DISCARD while interrupts are being injected, combined with a host operation that saves pending tables. No host credentials needed; x86-only fleets are unaffected.

What to do

Update to a patched kernel using the linked stable commits, then drain and reboot each arm64 KVM host - live guests must be migrated or stopped, as the fix is in the in-use vgic code. No runtime mitigation short of not exposing a virtual ITS to guests.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.