Linux crypto/ccp - SNP initialization on ioctl(SNP_COMMIT): The ccp driver initialised SNP from the SNP_COMMIT ioctl

Impact

The ccp driver initialised SNP from the SNP_COMMIT ioctl path, so a userspace process holding /dev/sev could drive SNP platform initialisation at a time the host was not expecting it - including while ordinary VMs are running. Triggering SNP platform state transitions underneath live guests is a route to destabilising the host and the confidential-computing state machine on it.

Who can reach it

Local, from a process with access to /dev/sev. On a well-run host that is the VMM or a management daemon, so the realistic path is a compromised control-plane component rather than a tenant.

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. Worth checking who actually has /dev/sev open on your hosts - the permissions on that node are the difference between 'root only' and 'any service account that got a bit too much'.

References