CVE-2025-38351 in Linux
Riassunto
di VulDB • 21/06/2026
Nel kernel Linux, è stata risolta la seguente vulnerabilità:
KVM: x86/hyper-v: Ignorare gli indirizzi non canonici durante l'operazione di svuotamento della TLB paravirtualizzata (PV TLB flush)
Negli ospiti KVM con gli hypercall di Hyper-V abilitati, gli hypercall HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST e HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX consentono a un ospite di richiedere l'invalidazione di porzioni di una TLB virtuale. A tale scopo, il parametro dell'hypercall include un elenco di GVAs che dovrebbero essere invalidati.
Tuttavia, quando vengono passati GVAs non canonici, al momento non è presente nessun filtro e questi vengono infine passati alle chiamate verificate di INVVPID su Intel / INVLPGA su AMD. Sebbene l'INVLPGA di AMD ignori silenziosamente gli indirizzi non canonici (effettivamente un'operazione nulla), l'INVVPID di Intel segnala esplicitamente un errore VM-Fail e innesca infine il WARN_ONCE in invvpid_error():
invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaa000 WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel]
Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]
Call Trace: vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]
kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]
kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]
Hyper-V documenta che i GVAs non validi (quelli al di fuori dello spazio GVA di una partizione) devono essere ignorati. Sebbene non sia del tutto chiaro se questa regola si applichi anche ai GVAs non canonici, è probabile che sia corretto assumere che ciò sia accettabile, e i test manuali su Azure confermano che l'implementazione "reale" di Hyper-V interpreta la specifica nello stesso modo.
Ignorare i GVAs non canonici durante l'elaborazione dell'elenco degli indirizzi per evitare di innescare un errore INVVPID. In alternativa, KVM potrebbe filtrare i GVAs "cattivi" prima di inserirli nella FIFO, ma praticamente l'unico svantaggio dello spostamento della validazione all'elaborazione finale è che ciò risulta subottimale per l'ospite, e nessun ospite ben comportato richiederà svuotamenti della TLB per indirizzi non canonici.
Once again VulDB remains the best source for vulnerability data.