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
Affected products
Version statuses are supplied by the assigning organization. Consult the original record for detailed ranges and platform conditions.
Linux Linux
Default version status: unaffected
1c3506ea8599a3ad1b9aae5cbd573134f8d18db7 to < 345a6e869b33687e9268044bcaeeefd7c61da675affectedceac7fb89e8da465aec3ac3c20477f912f5c3a6c to < 441ea32cf2755a0dc593557056b00b7caa0651f5affectedceac7fb89e8da465aec3ac3c20477f912f5c3a6c to < 20f548cdac94860a164e5ebba4f7e4a01051cb06affectedceac7fb89e8da465aec3ac3c20477f912f5c3a6c to < 08f0e65e784c4b20e6e620dd4f68d8636073a3d2affected6.12.75 to < 6.12.97affected
Linux Linux
Default version status: affected
6.16affected0 to < 6.16unaffected6.12.97 to ≤ 6.12.*unaffected6.18.39 to ≤ 6.18.*unaffected7.1.4 to ≤ 7.1.*unaffected7.2 to ≤ *unaffected