GPU VulnDB

Database/Kernel, userspace & hypervisor

KVM SVM SEV: races between encryption-context move and copy corrupt the mirror list and misdirect a VM reference

CVE-2026-74607Kernel, userspace & hypervisorcurated

Impact

sev_migrate_from() moves a mirror entry onto the owner's mirror_vms list without holding the owner's lock, unlike the other writers of that list, so a concurrent COPY_ENC_CONTEXT_FROM or VM destroy can corrupt it. Separately, sev_vm_destroy() can read an enc_context_owner that a concurrent MOVE changes underneath it, so kvm_put_kvm() lands on the wrong VM - a refcount error that can free a live VM structure. This is the SEV confidential-computing path: hosts running encrypted guests for tenants who chose them precisely because they do not trust the host operator. The consequence is host-side list corruption and misapplied references, i.e. crash-or-worse on the hypervisor that carries every other guest on the box.

Who can reach it

Local on the host, via the KVM ioctl interface: a process able to create VMs and issue KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM and KVM_CAP_VM_COPY_ENC_CONTEXT_FROM concurrently. In practice that is the VMM process (libvirt/QEMU) rather than a guest, so the exposure is on hosts where untrusted or semi-trusted code can drive VM creation.

What to do

Take the patched kernel from the linked stable commits, which serialise both paths behind a single global leaf lock. Rolling it out means draining guests off the host and rebooting the hypervisor - live migration of SEV guests is itself constrained, so plan the window. No runtime mitigation is described beyond not exposing the migrate/copy capabilities.

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.