Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - KVMx86/hyper-vPV TLB 刷新期间跳过非规范地址在启用了 Hyper-V 超级调用的 KVM 客户机中超级调用 HVCALL_FLUSH_VIRTual_ADDRESS_LIST 和 HVCALL_FLUSH_VIRTual_ADDRESS_LIST_EX 允许客户机请求使部分虚拟 TLB 无效。为此超级调用参数包含应作无效化的 GVA 列表。但是在传递非规范 GVA 时目前还没有进行适当的筛选它们最终会传递到 Intel / AMD 上的 INVLPGA 上已检查的 INVVPID 调用。AMD 的 INVLPGA 会静默忽略非规范地址实际上是无操作Intel 的 INVVPID 则明确表示 VM-Fail 并最终触发 invvpid_error():
    invvpid 失败ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 WARNINGCPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel] Modules 中链接的kvm_intel kvm 9pnet_virtio irqbypass fuse CPU6 UID: 0 PID: 326 Comm: kvm-vm 未受感染 6.15.0 #14 PREEMPT(optional) RIP: 0010: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但做出此假设可能没有问题并且 Azure 上的手动测试确认真正的 Hyper-V 会以相同的方式解释规范。处理地址列表时跳过非规范 GVA以避免引发 INVVPID 失败。或者KVM 可能会在插入到 FIFO 之前过滤掉错误的 GVA但实际上将验证推进到最终处理的唯一缺点是这样做对客户机而言不是最佳选择而且没有行为良好的客户机会为非规范地址。 (CVE-2025-38351)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

检测

Linux Distros 未修补的漏洞：CVE-2025-38351

medium Nessus 插件 ID 243866

未找到变更日志