Linux KVM/SEV - vCPU locking when synchronizing VMSAs for SNP launch finish: KVM did not lock all vCPUs

Impact

KVM did not lock all vCPUs while synchronising and encrypting VMSAs at SNP launch finish, so vCPU state could change underneath the encryption step. The VMSA is what the launch measurement covers; if it can move while being measured, the attestation you hand the tenant does not necessarily describe the VM that actually ran.

Who can reach it

Through the KVM SNP launch path, from the VMM process.

What to do

Fixed in the Linux kernel. Take the distro kernel update (RHEL/Rocky, Ubuntu, SLES) and reboot the host - no firmware, VBIOS or AGESA step. On a GPU fleet this is a cordon, drain and rolling reboot; plan it as normal kernel maintenance.

References

Related entries

• Linux KVM - VMSA sync on an already-launched SEV vCPU: KVM allowed synchronising vCPU state into the VMSACVE-2026-31593 · Linux KVM - VMSA sync on an already-launched SEV vCPUMedium
• Linux bnxt_en driver (backing store type from firmware response): A second firmware-controlled-index bug in the sameCVE-2026-43034 · Linux bnxt_en driver (backing store type from firmware response)Medium
• Linux kernel (drivers/infiniband/hw/irdma): A tenant that asks for a user QP while declaring a zero-size work-queueCVE-2026-68418 · Linux kernel (drivers/infiniband/hw/irdma)Medium
• Linux kernel (drivers/net/ethernet/mellanox/mlx5/core/lib): Every memory-key allocation carrying a steering-tag hintCVE-2026-72006 · Linux kernel (drivers/net/ethernet/mellanox/mlx5/core/lib)Medium
• Dell OMSA: missing authentication on a critical function lets a local user crash the management agentCVE-2026-81441 · Dell OpenManage Server Administrator (OMSA) managed-node agentMedium
• Dell OMSA: partial string comparison flaw lets a low-privileged local user cause a denial of serviceCVE-2026-81479 · Dell OpenManage Server Administrator (OMSA) managed-node agentMedium