0xcyberstan/cve-2026-53360-pocPoC pour CVE-2026-53360 : lecture/écriture hors limites du tas déclenchée par l'invité dans la gestion des changements d'état de page KVM SEV-SNP (PSC).
Preuve de concept pour une lecture et une écriture hors limites dans le tas (heap out‑of‑bounds) dans la gestion du changement d’état de page (PSC) SEV‑SNP de KVM. Un invité SEV‑SNP malveillant force le noyau hôte à parcourir un tableau d’entrées PSC au‑delà de la fin de son allocation de slab. Cela divulgue la disposition des objets kmalloc-cg-32 voisins et écrit une petite valeur contrôlée dans ceux-ci, et l’invité peut le répéter aussi souvent qu’il le souhaite.
Article complet : https://cyberstan.co.uk/sev-snp-oob/
| CVE | CVE-2026-53360 |
| Composant | Support hôte KVM SNP, arch/x86/kvm/svm/sev.c |
| Introduit | 9b54e248d264 (première gestion PSC KVM SNP, mai 2024, ~v6.10) |
| Corrigé | db3f219 (mainline, mai 2026, Cc: stable), étiqueté Fixes: 4af663c |
| Signalé | [email protected], 8 avril 2026 |
| Affecté | Chemin hôte SEV‑SNP uniquement. KVM n’active pas PSC pour les invités SEV‑ES simples. |
Tout invité SEV‑SNP peut corrompre le tas du noyau hôte et lire des informations sur sa disposition en envoyant une requête PSC malformée. Il s’agit de la direction invité → hôte : SEV‑SNP est conçu pour protéger l’invité d’un hôte non fiable, mais l’hôte doit quand même se défendre contre un invité malveillant, et ce gestionnaire ne le fait pas.
Cela nécessite du matériel SEV‑SNP réel. Cela ne peut pas être reproduit sur Intel, et la virtualisation imbriquée ne vous donnera pas d’invité SNP.
Matériel :
*.metal, Hetzner AX et similaires).Noyau hôte :
CONFIG_KASAN=y
CONFIG_KASAN_GENERIC=y
CONFIG_KVM=y
CONFIG_KVM_AMD=y
CONFIG_KVM_AMD_SEV=y
CONFIG_CRYPTO_DEV_SP_PSP=y
kvm_amd.sev=1 kvm_amd.sev_es=1 kvm_amd.sev_snp=1 kasan_multi_shot
cat /sys/module/kvm_amd/parameters/sev_snp # Y
ls /dev/sev # /dev/sev
Espace utilisateur hôte :
git clone https://github.com/AMDESE/qemu.git
cd qemu && git checkout snp-latest
mkdir build && cd build
../configure --target-list=x86_64-softmmu && make -j$(nproc)
Invité :
build-essential et linux-headers-$(uname -r) installés pour pouvoir y compiler le module.Les invités SEV‑SNP communiquent avec l’hôte via le GHCB, une page partagée de 4 Ko. Une requête PSC définit SW_EXITCODE à SVM_VMGEXIT_PSC (0x80000010), pointe SW_SCRATCH vers un descripteur et place la longueur du descripteur dans SW_EXITINFO2.
Le descripteur est un struct psc_buffer : un en‑tête de 8 octets suivi d’un tableau d’entrées de 8 octets. Il n’y a pas de champ de comptage explicite. L’hôte traite les entrées de hdr->cur_entry à hdr->end_entry, toutes deux contrôlées par l’invité.
struct psc_hdr {
u16 cur_entry;
u16 end_entry;
u32 reserved;
} __packed; /* 8 octets */
struct psc_entry {
u64 cur_page : 12;
u64 gfn : 40;
u64 operation : 4;
u64 pagesize : 1;
u64 reserved : 7;
} __packed; /* 8 octets */
Un invité GHCB v2+ est censé garder sa zone scratch à l’intérieur du tampon partagé de 2032 octets du GHCB, afin que l’hôte puisse réutiliser son mappage existant. (2032 - 8) / 8 = 253 entrées tiennent, ce qui correspond au maximum du protocole VMGEXIT_PSC_MAX_COUNT (253). Ce nombre n’a de sens que lorsque le tampon est réellement le tampon partagé.
Si l’invité pointe la zone scratch en dehors du GHCB, l’hôte ne peut pas utiliser son mappage, donc setup_vmgexit_scratch() alloue un tampon séparé de la taille demandée par l’invité. SNP ne devrait jamais emprunter ce chemin, mais rien ne l’empêche :
scratch_va = kvzalloc(len, GFP_KERNEL_ACCOUNT); /* len == exit_info_2, contrôlé par l'invité */
len vient directement de l’invité, et GFP_KERNEL_ACCOUNT place l’allocation dans les caches kmalloc-cg-N comptabilisés par cgroup. Demandez exit_info_2 = 24 et vous obtenez une allocation de 24 octets dans l’emplacement kmalloc-cg-32 de 32 octets : de la place pour l’en‑tête plus deux entrées. Tout ce qui dépasse entries[1] est la mémoire d’un autre objet.
Ensuite, snp_begin_psc() vérifie le nombre d’entrées par rapport à la constante du protocole, et non par rapport au tampon réellement alloué :
idx_end = hdr->end_entry;
if (idx_end >= VMGEXIT_PSC_MAX_COUNT) { /* vérifie 253, PAS la taille du tampon */
snp_complete_psc(svm, ...);
return 1;
}
for (idx = idx_start; idx <= idx_end; idx++) {
entry_start = entries[idx]; /* OOB dès que idx >= 2 */
...
}
Avec un tampon de 24 octets, il n’existe que deux entrées, mais la vérification autorise end_entry jusqu’à 252. Mettez‑le à 252 et la boucle parcourt environ 2 Ko au‑delà de l’allocation, à travers les objets slab voisins.
Chaque pas au‑delà de la fin réinterprète les 8 octets suivants de la mémoire slab comme un psc_entry et les exécute dans le code PSC. Cela donne trois choses :
entry.gfn et entry.operation de la mémoire que le tampon ne possédait pas. C’est la lecture hors limites (slab-out-of-bounds) que KASAN détecte.KVM_HC_MAP_GPA_RANGE, le code de terminaison écrit dans le même emplacement OOB : entries[idx].cur_page = entry.pagesize ? 512 : 1. Une ou deux petites valeurs dans les 12 bits de poids faible d’un mot que l’invité choisit, répétable.SW_EXITINFO2 signale l’index auquel elle s’est arrêtée. En augmentant end_entry une par une, on divulgue, slot par slot, si la mémoire adjacente a été décodée comme une opération nulle ou comme quelque chose qui a échoué, ce qui suffit pour trouver les limites des objets et distinguer zéro de non‑zéro.Chaque VMGEXIT réalloue le tampon scratch, donc des requêtes répétées atterrissent dans différents slots de la free list et permettent à l’invité de balayer les voisins plutôt que de rester bloqué sur un seul. Mis ensemble, cela donne une divulgation de la disposition du tas, l’écriture contrainte ci‑dessus, et une use‑after‑free entre les requêtes.
trigger.c est un module noyau invité. Chargez‑le dans un invité SEV‑SNP et il exécute quatre étapes contre l’hôte depuis un simple insmod :