GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux KVM arm64 vgic: LPI release races re-registration, erasing or leaking the xarray entry

CVSS 9.3CVE-2026-74568Kernel, userspace & hypervisorcurated

Impact

Dropping an LPI's refcount and evicting it from the VGIC LPI xarray were not one atomic step, so a guest that issues DISCARD while the LPI is still on a vCPU's ap_list and then re-maps the same INTID via MAPTI can race vgic_add_lpi() against the release path. On the direct-release path the newly registered LPI is erased from the xarray and freed out from under its user; on the deferred path the old LPI is overwritten and leaked, so it can never be released. The fix moves the refcount drop inside the xarray lock. For an arm64 GPU host this is guest-triggerable host kernel memory corruption or unbounded kernel memory growth - host crash is the expected outcome, and every accelerator on the node goes with it. This is a third, distinct vgic race from the two affinity-migration bugs in the same stable batch.

Who can reach it

Local to the host from inside a guest - any tenant VM on an arm64 KVM host with GICv3 ITS, using ordinary ITS commands (DISCARD, MAPTI). No host-side authentication.

What to do

Apply the stable kernel fix (three backport commits listed) and reboot each arm64 KVM host with VMs drained. No runtime mitigation is available; the record names no fixed distro release. Batch it with the other arm64 vgic fixes in the same stable update so one reboot clears all of them.

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.