GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux KVM arm64 vgic: double list_del when an LPI leaves the ap_list during migration

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

Impact

vgic_prune_ap_list() re-checked only that an interrupt's affinity was unchanged before moving it to another vCPU, assuming an interrupt with the same target was still queued on this vCPU's ap_list. vgic_flush_pending_lpis() can remove it and clear irq->vcpu while the locks are dropped, leaving enabled/pending/target_vcpu intact so the affinity check still passes - and list_del() runs a second time on an already-removed entry, corrupting host kernel list state. The fix adds an irq->vcpu == vcpu check. This is a distinct race from the reference-counting bug fixed alongside it, with its own trigger path and its own commits. Same operator consequence on arm64 GPU hosts: a guest corrupts host memory structures and can bring down the node and everything attached to it.

Who can reach it

Local to the host, driven from a guest on an arm64 KVM host with GICv3 ITS LPIs. Unauthenticated from the host's point of view - the guest drives it through normal ITS and redistributor accesses.

What to do

Apply the stable kernel fix (five backport commits listed) and reboot each arm64 KVM host after draining VMs. No runtime mitigation and no fixed distro version in the record; schedule it with the other vgic fixes landing in the same stable releases so a single reboot covers 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.