GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel KVM arm64: mismanaged userspace irqchip state triggers a kernel WARN on vCPU re-init

CVSS 5.5CVE-2024-53195Kernel, userspace & hypervisorcurated

Impact

KVM on arm64 tracked whether userspace owns the interrupt controller with a static key that could fall out of sync with reality: a vCPU initialised with a vPMU but no vGIC fails KVM_RUN partway through, leaving the timer enabled but the counter un-incremented, and a second KVM_ARM_VCPU_INIT then reaches WARN_ON() in kvm_timer_update_irq(). What the operator gets is a kernel warning and splat per occurrence, reachable from whatever process holds /dev/kvm - a hypervisor-level reliability bug rather than a guest escape. On arm64 GPU hosts (Grace/Grace-Hopper class nodes running tenant VMs), a tenant-facing VMM or any local user with /dev/kvm can produce these at will, filling the host log and tripping panic_on_warn fleets into a reboot that drains every accelerator on the node. The record shows no memory corruption, no host-to-guest or guest-to-host data exposure, and the fix is a cleanup that removes the static key entirely.

Who can reach it

Local user or VMM process with access to /dev/kvm on an arm64 host, issuing a specific KVM_ARM_VCPU_INIT / KVM_RUN / KVM_ARM_VCPU_INIT sequence. No network reach, nothing from inside an already-running guest, and x86 hosts are unaffected.

What to do

Pick up the stable kernel fix (commits in the record) from your distribution and reboot the arm64 hosts onto the patched kernel after draining them; this is in-tree KVM code with no module reload or runtime switch. Until then, hosts running with panic_on_warn should be aware that any holder of /dev/kvm can force the panic.

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.