The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush In KVM guests with Hyper-V hypercalls     enabled, the hypercalls HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX allow a     guest to request invalidation of portions of a virtual TLB. For this, the hypercall parameter includes a     list of GVAs that are supposed to be invalidated. However, when non-canonical GVAs are passed, there is     currently no filtering in place and they are eventually passed to checked invocations of INVVPID on Intel     / INVLPGA on AMD. While AMD's INVLPGA silently ignores non-canonical addresses (effectively a no-op),     Intel's INVVPID explicitly signals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():
    invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 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 documents that     invalid GVAs (those that are beyond a partition's GVA space) are to be ignored. While not completely clear     whether this ruling also applies to non-canonical GVAs, it is likely fine to make that assumption, and     manual testing on Azure confirms real Hyper-V interprets the specification in the same way. Skip non-     canonical GVAs when processing the list of address to avoid tripping the INVVPID failure. Alternatively,     KVM could filter out bad GVAs before inserting into the FIFO, but practically speaking the only downside     of pushing validation to the final processing is that doing so is suboptimal for the guest, and no well-     behaved guest will request TLB flushes for non-canonical addresses. (CVE-2025-38351)

Note that Nessus relies on the presence of the package as reported by the vendor.

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 がサイレントに非標準的なアドレスを無視するのに対し (効果的に no-op)、Intel の INVVPID は VM-Fail を明示的に伝達し、最終的に invvpid_error() の WARN_ONCE を発生させます。
    invvpid 失敗ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 警告CPU6 PID326 at arch/x86/kvm/vmx/vmx.c:482 invvpid_error+0x91/0xa0 [kvm_intel] モジュールのリンクkvm_intel kvm 9pnet_virtio irqbypass fuse 6.15.0 #14 CPU ：6 UID [kvm] kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm] 無効な GVAパーティションの GVA 空間を越えるが無視されるようにする Hyper-V ドキュメント。このルールが非標準的なGVAにも適用されるかどうかは完全には不明ですが、おそらくその仮定を作成するのは問題はないかもしれません。Azure での手動テストにより、実際の Hyper-V が同じように仕様を解釈することが確認されます。INVVPID エラーのトリップを回避するためにアドレスのリストを処理する際に非標準的な GVA をスキップします。あるいは、KVM が FIFO に挿入する前に不適切な GVA をフィルターで除外する可能性がありますが、実際上、最終的な処理への検証のプッシュに唯一のマイナスの要素は、ゲストにとって最適な方法で実行されることだけでなく、パフォーマンスの高いゲストは、可能性があります。CVE-2025-38351

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

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/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 依賴供應商報告的套件存在。

The remote Redhat Enterprise Linux 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2025:17377 advisory.

    The kernel packages contain the Linux kernel, the core of any Linux operating system.

    Security Fix(es):

    * kernel: security/keys: fix slab-out-of-bounds in key_task_permission (CVE-2024-50301)

    * kernel: KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush (CVE-2025-38351)

    * kernel: wifi: ath12k: Decrement TID on RX peer frag setup error handling (CVE-2025-39761)

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
243866	Linux Distros Unpatched Vulnerability : CVE-2025-38351	Nessus	Misc.	2025/8/5	2025/9/29	medium
243866	Linux Distros のパッチ未適用の脆弱性: CVE-2025-38351	Nessus	Misc.	2025/8/5	2025/9/29	medium
243866	Linux Distros 未修补的漏洞：CVE-2025-38351	Nessus	Misc.	2025/8/5	2025/9/29	medium
243866	Linux Distros 未修補的弱點：CVE-2025-38351	Nessus	Misc.	2025/8/5	2025/9/29	medium
266737	RHEL 9 : kernel (RHSA-2025:17377)	Nessus	Red Hat Local Security Checks	2025/10/6	2025/10/6	high

检测

插件搜索

medium

medium

medium

medium

high