Linux kernel KVM arm64: vCPU event ioctls before init hit a BUG() and take down the host

CVE-2025-40102Kernel, userspace & hypervisorcurated

Impact

KVM on arm64 accepted KVM_SET_VCPU_EVENTS for a vCPU that had not yet been through KVM_ARM_VCPU_INIT, so exception routing and injection ran against uninitialized state. In the reported case the injection code and the hypervisor disagree about whether the vCPU has a 32-bit EL1, the vCPU ends up in a mode illegal for AArch64, and the next injection trips the BUG() in exception_target_el() - a kernel oops on the host, not a contained guest fault. On arm64 accelerator nodes (Grace-class hosts running tenant VMs), one process holding /dev/kvm can drop the whole host and every co-resident GPU with it, which is the expensive kind of outage because the node has to be drained after the fact rather than before. The fix rejects the ioctls outright before init. The record carries no CVSS score.

Who can reach it

Local: any process that can open /dev/kvm and issue vCPU ioctls, found by syzkaller. No authentication beyond access to the KVM device node; no remote or in-guest path - it is the VMM-facing API that is abused.

What to do

Apply the stable-kernel fix for your branch (five backports are listed on the record, e.g. b498f0da45a3) and drain plus reboot each arm64 hypervisor node; the fix is in the KVM core path and is not picked up by restarting VMMs. Meanwhile, restrict /dev/kvm to the VMM service account rather than to tenant-reachable processes.

References

https://nvd.nist.gov/vuln/detail/CVE-2025-40102 https://git.kernel.org/stable/c/b498f0da45a388b40195f7198455c62fe366a372 https://git.kernel.org/stable/c/0aa1b76fe1429629215a7c79820e4b96233ac4a3 https://git.kernel.org/stable/c/7b854e68365a84dfa984ee81268e10b9311ac9d2

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.