GPU VulnDB

Database/Firmware, BMC & network fabric

Linux KVM - intra-host migration/mirroring of SEV-SNP VMs: MULTI-TENANT ISOLATION: KVM allowed intra-host migration

CVE-2026-72286Firmware, BMC & network fabriccurated

Impact

MULTI-TENANT ISOLATION: KVM allowed intra-host migration and mirroring of SEV-SNP VMs even though the feature was never fully implemented for SNP - SNP-specific state such as the guest request mutex and message counters is not carried across. Migrating or mirroring an SNP VM through this path lands it in an inconsistent confidential state, which is a route to breaking the guest's isolation and to host-side memory corruption. At 8.8 this is the most severe SEV-related kernel issue in the current set.

Who can reach it

Reachable through the KVM ioctl surface used for intra-host migration/mirroring - so a process with access to /dev/kvm and the ability to drive migration, i.e. the VMM. In a multi-tenant control plane that is your orchestrator, which makes control-plane compromise the realistic path in.

What to do

Fixed in the Linux kernel - KVM/x86 SEV code or the ccp/PSP driver. Take the distro kernel update (RHEL/Rocky, Ubuntu, SLES) and **reboot the host**; SEV/SNP hypervisor paths cannot be live-patched in any meaningful way, and SNP platform init/shutdown is not safe to cycle under running guests. Drain confidential-VM tenants, reboot, then re-admit. No firmware, VBIOS or AGESA step needed, which makes this one of the cheaper classes of SEV fix to roll out. The upstream fix simply rejects the operation for SNP VMs. Until you are patched, disable intra-host migration and VM mirroring for SEV-SNP guests in your VMM configuration - that removes the reachable path without a reboot.

References

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.