CyberRota Analysis
AI-GeneratedThe vulnerability in the Linux kernel affects the crypto subsystem, specifically related to the Secure Encrypted Virtualization (SEV) feature, where improper handling of SNP initialization during ioctl calls could lead to a global zeroing of the MSR_VM_HSAVE_PA register. This could potentially crash the host if a VMRUN is executed for an active virtual machine. Organizations running Linux with KVM should prioritize addressing this issue to prevent possible system instability and data loss.
Original NVD Description
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Do not initialize SNP for ioctl(SNP_CONFIG) Sashiko notes: > if SEV initialization fails and KVM is actively running normal VMs, could a > userspace process trigger this code path via /dev/sev ioctls (e.g., > SEV_PDH_GEN) and zero out MSR_VM_HSAVE_PA globally? Would the next VMRUN > execution for an active VM trigger a general protection fault and crash the > host? Refuse to re-try initialization if SNP is not already initialized for SNP_CONFIG. This is technically an ABI break: before if SNP initialization failed it could be transparently retriggered by this ioctl, and if no VMs were running, everything worked fine. Hopefully this is enough of a corner case that nobody will notice, but someone does, there are a few options: * do something like symbol_get() for kvm and refuse to initialize if KVM is loaded * check each cpu's HSAVE_PA for non-zero data before re-initializing * once initialization has failed, continue to refuse to initialize until the ccp module is unloaded