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

  - KVM：SEV：当释放 CPU 掩码指针时，使运行 CPU 掩码指针无效have_run_cpus化 当释放掩码时，尤其是在 __sev_guest_init（） 的错误路径中，使 KVM 不必巧妙地使用 sev->active 来跟踪掩码是否已释放。正如 Sashiko 所指出的，盲目释放 sev_vm_destroy（） 中的掩码会导致双重释放，前提是在 __sev_guest_init（） 失败的情况下释放掩码。
    在帮助程序中抛出逻辑，因为使指针无效非常困难且奇怪，因为当 CPUMASK_OFFSTACK=n 时have_run_cpus会成为单一条目数组。故意不使用 CPUMASK_VAR_NULL，因为当 cpumask 在堆栈上时无法直接分配它，例如需要使用本地变量和 memcpy（），这太荒谬了。此外，尽管清除堆栈上的位掩码是不必要的副作用，并且可以说是不需要的副作用，但考虑到结构是零分配的，KVM 绝对依赖于“0”作为空值。适时添加一个 alloc（） 辅助函数以与 free（） 配对;有足够的呼叫站点让这样做变得值得。（CVE-2026-98719）

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

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

  - KVM：SEV：釋放遮罩時，使執行 CPU 遮罩指標無效 釋放遮罩時，特別是在 __sev_guest_init（） 的錯誤路徑中，have_run_cpus無效，這樣 KVM 就不必巧妙地使用 sev->active 來追蹤遮罩是否已釋放。正如 Sashiko 所指出的，在 sev_vm_destroy（） 中盲目釋放遮罩會導致雙重釋放，如果遮罩在 __sev_guest_init（） 失敗時被釋放。
    將邏輯扔到協助程式中，因為當 CPUMASK_OFFSTACK=n 時have_run_cpus是單輸入數組，因此使指標無效非常困難且奇怪。故意不要使用 CPUMASK_VAR_NULL，因為當 cpumask 在堆疊上時，它無法直接分配，例如需要使用局部變數和 memcpy（），這非常荒謬。此外，雖然清除堆疊上的位元遮罩是一個不必要且可以說是不需要的副作用，但鑑於結構是零分配的，KVM 絕對依賴「0」作為空值。投機性地新增 alloc（） 協助程式以與 free（） 配對;有足夠的通話網站讓這樣做變得值得。（CVE-2026-98719）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - KVM:SEV:解放するときに CPU マスクポインターを実行する値を Null にします マスクを解放するとき、特に __sev_guest_init() のエラーパスで、have_run_cpus を Null にします。これにより、マスクが解放されているかどうかを追跡するために、KVM が sev->active をさりげなく使用する必要がありません。Sashiko 氏が指摘しているように、sev_vm_destroy() でマスクを盲目的に解放すると、__sev_guest_init() が失敗した場合にマスクが解放されると、二重解放が発生します。
    ポインターを null 化することは、CPUMASK_OFFSTACK=n の場合、have_run_cpus が単一エントリ配列であるため、もどかしいほど難しく、おかしいこととして、ヘルパーにロジックを投入してください。cpumaskがオンスタックの場合、ローカル変数とmemcpy()を使用する必要があるなど、直接割り当てできないため、CPUMASK_VAR_NULLは意図的に使用しないでください。さらに、オンスタックのビットマスクをクリアすることは不要で、間違いなく望ましくない副作用ですが、構造体がゼロに割り当てられている場合、KVM は絶対に null 値である「0」に依存します。free() とペアになるように alloc() ヘルパーを時機的に追加します。そうする価値があるのに十分なコールサイトがあります。(CVE-2026-98719)

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

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

  - In the Linux kernel, the following vulnerability has been resolved: KVM: SEV: Nullify have run CPUs mask     pointer when freeing it Nullify have_run_cpus when freeing the mask, particularly in the error path of
    __sev_guest_init(), so that KVM doesn't have to subtly use sev->active to track whether or not the mask     has been freed. As pointed out by Sashiko, blindly freeing the mask in sev_vm_destroy() results in a     double-free if the mask is freed if __sev_guest_init() fails. Throw the logic in a helper as nullifying     the pointer is frustratingly difficult and weird due to have_run_cpus being a single-entry array when     CPUMASK_OFFSTACK=n. Deliberately don't use CPUMASK_VAR_NULL, as it's not directly assignable when the     cpumask is on-stack, e.g. requires using a local variable and a memcpy(), which is beyond ridiculous.
    Furthermore, while clearing the on-stack bitmask is an unnecessary and arguably unwanted side effect, KVM     absolutely relies on '0' being the null value given that the struct is zero-allocated. Opportunistically     add an alloc() helper to pair with free(); there are just enough call sites to make doing so worthwhile.
    (CVE-2026-98719)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
367586	Linux Distros 未修补的漏洞：CVE-2026-98719	Nessus	Misc.	2026/10/20	2026/11/11	medium
367586	Linux Distros 未修補弱點：CVE-2026-98719	Nessus	Misc.	2026/10/20	2026/11/11	medium
367586	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98719	Nessus	Misc.	2026/10/20	2026/11/11	medium
367586	Linux Distros Unpatched Vulnerability : CVE-2026-98719	Nessus	Misc.	2026/10/20	2026/11/11	medium

检测

插件搜索

medium

medium

medium

medium