CVE-2026-64307

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
Configurations

Configuration 1 (hide)

OR cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*

History

24 Oct 2026, 13:10

Type Values Removed Values Added
Summary
  • (es) En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: crypto: ccp - No inicializar SNP para ioctl(SNP_CONFIG) Notas de Sashiko: > si la inicialización de SEV falla y KVM está ejecutando activamente máquinas virtuales normales, ¿podría un proceso de espacio de usuario activar esta ruta de código a través de ioctls de /dev/sev (p. ej., SEV_PDH_GEN) y poner a cero MSR_VM_HSAVE_PA globalmente? ¿La siguiente ejecución de VMRUN para una máquina virtual activa desencadenaría una falla de protección general y bloquearía el host? Rechazar reintentar la inicialización si SNP no está ya inicializado para SNP_CONFIG. Esto es técnicamente una ruptura de ABI: antes, si la inicialización de SNP fallaba, podía ser re-activada transparentemente por este ioctl, y si no había máquinas virtuales en ejecución, todo funcionaba bien. Con suerte, este es un caso tan excepcional que nadie lo notará, pero si alguien lo hace, hay algunas opciones: * hacer algo como symbol_get() para kvm y negarse a inicializar si KVM está cargado * verificar el HSAVE_PA de cada CPU en busca de datos no nulos antes de reinicializar * una vez que la inicialización ha fallado, continuar negándose a inicializar hasta que el módulo ccp sea descargado

Information

Published : 2026-07-25 10:17

Updated : 2026-10-24 13:10


NVD link : CVE-2026-64307

Mitre link : CVE-2026-64307

CVE.ORG link : CVE-2026-64307


JSON object : View

Products Affected

linux

  • linux_kernel