GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel KVM x86: rechecking L1 I/O intercepts on userspace exit completion leaves pio.count non-zero

CVSS 7.9CVE-2025-40026Kernel, userspace & hypervisorcurated

Impact

When KVM finishes emulating an instruction that exited to userspace for port I/O, it re-evaluated the L1 I/O permission bitmaps even though it had already committed to performing the access. If L1 or host userspace flips the bitmap during the exit, KVM treats the access as intercepted after the fact, leaves vcpu->arch.pio.count non-zero and hits a WARN, found by syzkaller toggling interception mid-exit. The exposure is to nested virtualization: a guest that can run its own L1 hypervisor can wedge or destabilize the vCPU on the host. On GPU fleets that hand tenants nested-capable VMs with passed-through accelerators, the affected vCPU thread is the one holding the GPU, and the only clean recovery is killing the VM. The fix pivots on EMULTYPE_NO_DECODE to detect completion and skip the recheck.

Who can reach it

Local to the host: a user with /dev/kvm who can create a VM and run nested guests, or a tenant inside a nested-virtualization-enabled VM. No remote or network path; authentication to the host or to the guest is required.

What to do

Apply the stable kernel update for your branch (commits listed in the references) and reload the kvm/kvm_intel modules or reboot the node - module reload requires every VM on the host to be stopped first, so in practice this is a drain-and-reboot per hypervisor node. Where patching must wait, disabling nested virtualization for tenant VMs removes the path.

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.