GPU VulnDB

Database/Kernel, userspace & hypervisor

KVM arm64 vgic-its: restored ITS device table entry with oversized num_eventid_bits is not rejected

CVSS 9.0CVE-2026-64106Kernel, userspace & hypervisorcurated

Impact

On arm64 hosts, userspace restoring a virtual ITS Device Table Entry could encode more EventID bits than the virtual ITS supports. The live MAPD path rejected that, but vgic_its_restore_dte() stored the out-of-range value, which then reached vgic_its_restore_itt() and turned into an oversized scan_its_table() range. The CVSS vector marks a scope change with high impact on confidentiality and availability, consistent with a host-side memory read and crash driven from the restore path. The exposure is limited to arm64 KVM hosts - Grace-Hopper and other Arm GPU nodes - and the trigger is the VMM process performing a save/restore or migration, which is normally a trusted component; a GPU cloud that lets tenants supply or influence VM state blobs for live migration is the case that matters.

Who can reach it

Local - whatever userspace drives the KVM ITS save/restore ioctls on an arm64 host, typically QEMU or another VMM. The CVSS vector lists no privileges required at the local attack surface; in practice an attacker needs to control or influence the migration state fed to the VMM.

What to do

Update the host kernel to a stable release that rejects restored DTEs with num_eventid_bits above VITS_TYPER_IDBITS (commits linked in the record) and reboot the affected arm64 hosts - a drain and reboot per node, since the fix is in the KVM arm64 vgic code. Until patched, do not accept VM state blobs from untrusted sources for live migration or restore on arm64 GPU hosts. x86 hosts are not affected.

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.