GPU VulnDB

Database/Kernel, userspace & hypervisor

QEMU VAPIC hypercall lets a privileged guest write into locked SMRAM and run code in SMM

CVSS 8.2CVE-2026-81627Kernel, userspace & hypervisorcurated

Impact

The VAPIC setup hypercall does not check that the writable RAM alias it creates stays inside the option ROM window, so a guest with root can point that alias at locked SMRAM. That defeats the chipset D_LCK protection and lets the guest inject code into System Management Mode memory - the most privileged execution context on the machine, below the hypervisor. On a GPU cloud that rents VMs with passthrough accelerators, this is a tenant-to-host trust boundary break: SMM code persists across guest reboots and is invisible to the host kernel, so a compromised node cannot be trusted again by wiping the guest. Red Hat scores it 8.2 with scope change, reflecting the escape out of the VM.

Who can reach it

A privileged (root) user inside a guest on a Q35/KVM machine type. No access to the host or the management network is needed; local guest privilege is enough.

What to do

Apply the QEMU update from your distribution when it ships - Red Hat tracks this for RHEL 6 through 10, RHEL for NVIDIA 26 and OpenShift Container Platform 4, and the upstream fix is tracked in the QEMU project work item. Updating QEMU requires restarting or live-migrating every guest on the host to pick up the new binary, so plan an evacuation pass across the fleet rather than an in-place restart. Until patched, guests whose root is untrusted should not run on hosts you need to keep clean.

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.