CVE-2026-64307 in Linuxinformation

Résumé

par VulDB • 25/07/2026

Dans le noyau Linux, la vulnérabilité suivante a été corrigée :

crypto: ccp - Ne pas initialiser SNP pour ioctl(SNP_CONFIG)

Les remarques de Sashiko :

> Si l'initialisation SEV échoue et que KVM exécute activement des machines virtuelles (VM) normales, un processus utilisateur pourrait-il déclencher ce chemin d'exécution via les ioctls /dev/sev (par exemple, SEV_PDH_GEN) et réinitialiser à zéro MSR_VM_HSAVE_PA globalement ? L'exécution suivante de VMRUN pour une VM active provoquerait-elle une faute de protection générale et ferait-elle planter l'hôte ?

Refuser de réessayer l'initialisation si SNP n'est pas déjà initialisé pour SNP_CONFIG.

Il s'agit techniquement d'une rupture d'ABI : auparavant, en cas d'échec de l'initialisation de SNP, celle-ci pouvait être redéclenchée transparentement par cet ioctl, et tout fonctionnait correctement si aucune VM n'était exécutée. On espère qu'il s'agit là d'un cas suffisamment marginal pour passer inaperçu ; toutefois, si quelqu'un le remarque, plusieurs options sont possibles :

* effectuer une opération similaire à symbol_get() pour kvm et refuser l'initialisation si KVM est chargé * vérifier les données HSAVE_PA de chaque CPU avant de réinitialiser, en s'assurant qu'elles ne sont pas nulles * après un échec d'initialisation, continuer à refuser toute nouvelle initialisation jusqu'à ce que le module ccp soit déchargé

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Responsable

Linux

Réserver

19/07/2026

Divulgation

25/07/2026

Modérer

accepté

Entrée

VDB-383105

CPE

prêt

EPSS

0.00215

KEV

non

Activités

très faible

Sources

Do you need the next level of professionalism?

Upgrade your account now!