GPU VulnDB

Database/Kernel, userspace & hypervisor

KVM arm64 vGICv2: guest write of an out-of-range GICV_DIR INTID triggers a host WARN and panics panic_on_warn hosts

UnscoredCVE-2026-89727Kernel, userspace & hypervisorcurated

Impact

vgic_v2_deactivate() passed the INTID a guest wrote to GICV_DIR straight to vgic_get_vcpu_irq() and treated a failed lookup as impossible, flagging it with WARN_ON_ONCE(). A guest controls that value: GICv2 has no LPIs, so any INTID outside the implemented SGI, PPI and SPI ranges returns NULL, and a guest running with EOImode==1 can hit it at will. On a host configured with panic_on_warn - a common hardening and crash-dump setting - an unprivileged guest takes down the hypervisor and every other VM on the node. On an Arm GPU host that means losing all co-tenant instances on that box, and an unplanned reboot of accelerators that were mid-job. Without panic_on_warn the effect is a log-spamming WARN only.

Who can reach it

Any tenant with a VM on an arm64 KVM host using the emulated GICv2 interrupt controller. Guest-kernel privilege inside their own VM is sufficient; no host credentials needed.

What to do

Patch arm64 hosts to a stable kernel containing the change that drops the WARN and ignores failed lookups, then drain and reboot each host. As an immediate mitigation, turn off panic_on_warn on arm64 KVM hosts - that reduces the impact to noisy logs without a reboot - or move guests to GICv3. x86 hosts are unaffected.

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.