CVE-2026-53360
KVM: SEV: Richiedere l'area scratch in-GHCB se è in uso GHCB v2+
- Pubblicato
- 4 lug 2026
- Aggiornato
- 5 ago 2026
- Assegnazione CNA
- Linux
- Evidenza osservata
- 8 ago 2026
CVSS primario
nvd · CVSS 3.1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:HBasso · prossimi 30 giorni
- Percentile
- 15,8%
- Data del modello
- 21 set 2026
L'EPSS è una stima statistica, non una certezza o una misura di impatto. Combinalo con CVSS, stato KEV, esposizione e ambiente.
Riepilogo
Nel kernel Linux, è stata risolta la seguente vulnerabilità: KVM: SEV: richiedere l'area scratch in-GHCB se è in uso GHCB v2+. Secondo la specifica GHCB, quando si utilizza GHCB v2+, l'area scratch software deve risiedere nel buffer condiviso del GHCB. Nota: richieste come quelle di Page State Change (PSC) _dipendono_ da questo comportamento, poiché il guest non può fornire una lunghezza quando effettua la richiesta, ovvero la dimensione del payload del guest è limitata dalla dimensione del buffer condiviso. La mancata imposizione dell'uso del GHCB, insieme a una serie di altri difetti, consente a un guest SNP malintenzionato di corrompere la memoria heap del kernel dell'host e di divulgare informazioni sul layout dell'heap dell'host. setup_vmgexit_scratch() alloca un buffer tramite kvzalloc(exit_info_2), dove exit_info_2 è controllato dal guest. Con exit_info_2=24, si ottiene un'allocazione di 24 byte in kmalloc-cg-32 (oggetti slab da 32 byte). Il buffer contiene un psc_hdr di 8 byte seguito da struct psc_entry di 8 byte, quindi solo entries[0] ed entries[1] rientrano nei limiti. snp_begin_psc() valida end_entry rispetto a VMGEXIT_PSC_MAX_COUNT (253) ma NON rispetto alla dimensione effettiva del buffer: ```c idx_end = hdr->end_entry; if (idx_end >= VMGEXIT_PSC_MAX_COUNT) { // checks 253, not buffer snp_complete_psc(svm, ...); return 1; } for (idx = idx_start; idx <= idx_end; idx++) { entry_start = entries[idx]; // OOB when idx >= 2 ``` Il guest imposta end_entry=10+, facendo sì che l'host iteri su entries[2+], che sono fuori dai limiti (OOB) rispetto agli oggetti slab adiacenti. Per ogni voce OOB: - L'host legge 8 byte (lettura OOB / oracolo per la fuga di informazioni) - Se i dati superano la validazione PSC, __snp_complete_one_psc() scrive cur_page = 1 o 512 nella voce (scrittura OOB, sev.c:3806) - Se la validazione fallisce, la risposta di errore rivela se la memoria adiacente è zero o diversa da zero (divulgazione di informazioni al guest) Il guest controlla la dimensione dell'allocazione (exit_info_2), l'intervallo di voci (cur_entry/end_entry) e può generare un numero illimitato di VMGEXIT per colpire ripetutamente diverse posizioni degli slab. Sfruttando la varietà di bug, un guest SEV-SNP malintenzionato può: - Leggere OOB gli oggetti kmalloc-cg-32 adiacenti (divulgazione del layout dell'heap) - Scrivere OOB i bit di cur_page negli oggetti adiacenti (corruzione dell'heap) - Innescare condizioni use-after-free attraverso i VMGEXIT Ad esempio, con KASAN abilitato, un singolo insmod del modulo guest del PoC produce 73 report KASAN: BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x126/0x890 Read of size 8 at addr ffff888219ffb5e0 by task qemu-system-x86/2199 BUG: KASAN: slab-out-of-bounds in snp_begin_psc+0x468/0x890 Write of size 8 at addr ffff888351566648 by task qemu-system-x86/2199 The buggy address belongs to the object at ffff888XXXXXXXXX which belongs to the cache kmalloc-cg-32 of size 32 The buggy address is located N bytes to the right of allocated 32-byte region [ffff888XXXXXXXXX, ffff888XXXXXXXXX) Riepilogo: 62 slab-out-of-bounds (letture e scritture oltre l'allocazione) 7 slab-use-after-free 4 use-after-free Tutto il merito va a Stan per la splendida descrizione e il reproducer! [sean: write changelog]
Utilizzo responsabile
Utilizza le informazioni sulla vulnerabilità solo sui sistemi che possiedi o che sei autorizzato a testare. Kitploit si collega ai metadati della ricerca pubblica e non memorizza codici exploit o payload dannosi.