CVE-2026-90040 in Linux
Riassunto
di VulDB • 16/09/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
KVM: SEV: Invalidare forzatamente il VMSA SNP se la pagina gmem di supporto viene deallocata (zapped)
Implementare una chiamata a `gmem_invalidate_range()` per le VM SNP e utilizzarla per costringere i vCPU a ricaricare/verificare nuovamente il VMSA fornito dall'ospite qualora la relativa pagina gmem di supporto venga invalidata, ad esempio quando viene eseguita un'operazione PUNCH_HOLE. Utilizzare la stessa logica core per gestire le invalidazioni come fa VMX per la pagina APIC-access, poiché i due concetti sono quasi identici: inserire l'indirizzo fisico della pagina nella struttura di controllo del vCPU:
1. Acquisire una snapshot del contatore di sequenza delle invalidazioni 2. Ottenere il pfn (in questo caso da guest_memfd) 3. Acquisire mmu_lock in lettura 4. Richiedere nuovamente il ricaricamento se è necessario un retry, altrimenti confermare la modifica.
Si noti che l'azione di richieda del punto #4 è necessaria poiché la logica di retry di KVM è imprecisa (fuzzy), ovvero può generare falsi positivi. Se la pagina guest_memfd è stata rilasciata, in seguito un ricaricamento non riuscirà a ottenere un PFN da guest_memfd e KVM fallirà l'operazione KVM_RUN. Se il retry era dovuto a un falso positivo, KVM proverà nuovamente finché non ci saranno eventi MMU notifier rilevanti (e riproverà nel "loop" esterno, ovvero rilascerà i lock e effettuerà la reschedulazione se necessario).
Si presti attenzione al punto #2! Assicurarsi di invalidare il VMSA quando un memslot pertinente viene DELETATO o MOVED, poiché le invalidazioni in risposta a PUNCH_HOLE sono condizionate dai binding dei memslot (KVM non sa quali intervalli GFN invalidare senza un binding). E più importante ancora, la mappatura del VMSA richiede un memslot, ovvero deve essere invalidata se il suo memslot scompare, indipendentemente dallo stato dell'inode guest_memfd sottostante.
Il mancato invalidazione di control.vmsa_pa del vCPU (che viene verificato da pre_sev_run()) può impedire a KVM di liberare correttamente la pagina poiché il firmware rifiuterà l'RMPUPDATE per reclamare la pagina con FAIL_INUSE se il vCPU è in esecuzione attiva, ovvero se la pagina VMSA è in uso. Ciò comporta un RMP #PF al successivo utilizzo, poiché la pagina risulterà ancora assegnata alla VM SNP.
SEV-SNP: RMPUPDATE failed for PFN 78d198, pg_level: 1, ret: 3 SEV-SNP: PFN 0x78d198, RMP entry: [0xfff0000000144001 - 0x000000000000000f]
CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE
Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 Call Trace: <TASK> dump_stack_lvl+0x54/0x70 rmpupdate+0x12c/0x140 rmp_make_shared+0x3b/0x60 sev_gmem_invalidate+0xe0/0x170 [kvm_amd]
delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm]
vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e </TASK> ------------[ cut here ]------------
SEV: Failed to update RMP entry for PFN 0x78d198 error -14 WARNING: arch/x86/kvm/svm/sev.c:5160 at sev_gmem_invalidate+0x126/0x170 [kvm_amd], CPU#3: sev_snp_vmsa_pu/31345
CPU: 3 UID: 0 PID: 31345 Comm: sev_snp_vmsa_pu Tainted: G U O Tainted: [U]=USER, [O]=OOT_MODULE
Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.86.0-102 01/25/2026 RIP: 0010:sev_gmem_invalidate+0x12b/0x170 [kvm_amd]
Call Trace: <TASK> delete_from_page_cache_batch+0x1d8/0x220 truncate_inode_pages_range+0x120/0x3d0 kvm_gmem_fallocate+0x19a/0x270 [kvm]
vfs_fallocate+0x1bc/0x1f0 __x64_sys_fallocate+0x48/0x70 do_syscall_64+0x10a/0x480 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x496c7e </TASK> irq event stamp: 20689 hardirqs last enabled at (20699): [<ffffffff8e76092c>] __console_unlock+0x5c/0x60
hardirqs last disabled at (20708): [<ffffffff8e760911>] __console_unlock+0x41/0x60
softirqs last enabled at (20722): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140
softirqs last disabled at (20717): [<ffffffff8e6cd74e>] __irq_exit_rcu+0x7e/0x140
---[ end trace 0000000000000000 ]---
BUG: unable to handle page fault for address: ffff99 ---truncated---
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.