Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - KVMx86/hyper-vPV TLB 排清期間略過非正式位址在已啟用 Hyper-V hypercall 的 KVM 來賓中hypercall HVCALL_FLUSH_VIRTUA_ADDRESS_LIST 和 HVCALL_FLUSH_VIRTUA_ADDRESS_LIST_EX 允許來賓要求無效化部分虛擬 TLB。為此hypercall 參數會包含應作廢的 GVA 清單。不過傳遞非正式 GVA 時目前尚無適當的篩選而且這些 GVA 最終會傳遞給 Intel 上的 INVVPID/AMD 上的 INVLPGA 的已檢查叫用。雖然 AMD 的 INVLPGA 會以無訊息模式忽略非正式位址 (實際上是非 op)但 Intel 的 INVVPID 會明確發出 VM-Fail 的訊號並最終觸發 invvpid_error() 中的 WARN_ONCE
    invvpid 失敗ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 警告 CPU 6 PIDarch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 326 [kvm_intel] 模組連結於kvm_intel kvm 9pnet_virtio irqbypass fuse CPU6 UID0 PID326 通訊kvm-vm 未受污染 6.15.0 #14 PREEMPT(自發) RIP0010:invvpid_error+0x91/0xa0 [kvm_intel] 呼叫追踪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 文件指出將忽略無效的 GVA (超出磁碟分割 GVA 空間的 GVA)。雖然不完全清楚此規則是否也適用於非正式 GVA但可以做這個假設而且 Azure 上的手動測試可確認真正的 Hyper-V 以相同方式解譯規格。處理位址清單時略過非正式 GVA以避免觸發 INVVPID 失敗。或者KVM 可在將錯誤的 GVA 插入 FIFO 之前將其篩除但實際上將驗證推至最後處理的唯一不足為對來賓而言效果不佳且沒有運作良好的來賓會針對非正式位址。 (CVE-2025-38351)

請注意，Nessus 依賴供應商報告的套件存在。

偵測

Linux Distros 未修補的弱點：CVE-2025-38351

high Nessus Plugin ID 243866

版本 1.9