GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux KVM x86: per-vCPU MMIO cache uses address space 0, letting a guest force bogus MMIO exits

CVSS 8.8CVE-2026-99082Kernel, userspace & hypervisorcurated

Impact

The per-vCPU MMIO cache is tagged with a memslot generation but both the fill and validation paths call kvm_memslots(), which always selects address space 0 even when the vCPU is executing in SMM and using address space 1. An update to the SMM memslots can therefore leave a stale SMM-address-space entry looking valid after the vCPU returns to normal mode, and the guest can make an access to ordinary RAM be reported to userspace as KVM_EXIT_MMIO. When the VMM completes that exit through its RAM mapping, the backing page is written without passing through KVM's write-tracking path; if the page backs a nested EPT table, KVM may keep using shadow translations derived from the stale contents, which the WARN_ON_ONCE() in kvm_mmu_write_protect_fault() flags. On a GPU node running tenant VMs with passthrough or vGPU, this is a guest-triggered host-side memory-management inconsistency in the hypervisor that sits under every tenant on the box - the practical risk is host-side corruption of nested paging state rather than a demonstrated container escape, and it needs a guest that enters SMM plus memslot churn, so it is not a drive-by.

Who can reach it

A local, authenticated guest - any tenant who can boot their own VM image on a KVM host and execute in SMM while the VMM updates SMM memslots. No host account and no network access are needed; the host userspace VMM must complete the resulting MMIO exit.

What to do

Pick up the stable kernel fix that switches the MMIO cache fill and validation to the vCPU's active memslots (kvm_vcpu_memslots()); the stable commits are linked in the record. There is no runtime mitigation, so this is a host kernel upgrade: drain the GPU node, migrate or stop tenant VMs, reboot into the patched kernel. Nodes that do not expose SMM-capable guests or nested virtualization are far less interesting to patch urgently, but the fix still has to land with a reboot. No fixed mainline release number is stated in the record beyond the listed commits.

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.