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

  - KVM：x86/mmu：处理 #NPF 退出代码中设置的 SS 位 在从 Windows 11 运行 Hyper-V 时，KVM 会看到嵌套页面错误代码中设置的 SS 位，这些错误代码会针对遮蔽的 NPT 产生。AMD 手册不清楚何时设置 SS，包括在未在 VMCB 的 MISC_CTL 字段中设置 SupervisorShadowStackEn（位 6）时是否可设置 SS。然而，非预期的 SS 位还是会在 permission_fault（） 中造成越界访问，无论是被视为 WARN 还是 UBSAN 报告：内核：UBSAN： array-index-out-of-bounds in arch/x86/kvm/mmu.h：225：27 内核：索引 34 超出了“u16 [16]”类型的范围（在此情况下，页面错误代码为 34*2=0x44，即 SS|U;报告显示 SS|U|W 也发生）。通过删除 SS 和（使用警告）不属于 permission_fault（） 预期接收的任何位，修复对未知错误代码的处理。同时，鉴于硬件设置 SS 的时间存在不确定性，构造错误的错误代码时遵循处理器的行为，并保留传递到 FNAME（walk_addr_generic） 的 SS 位。尽管行为令人惊讶，但 Hyper-V 有可能预料到了这一点（除非找到 MBEC/GMET，否则 Hyper-V 甚至不会启用 CET！），因此将错误反映到 L1 时应保留信息，而非无条件将其丢弃。Bisection 显示这在提交 687ee95c1b6d（KVM：nSVM：为客户机启用 GMET）时开始发生，即使从 Linux 6.18开始 SHSTK 可供客户机使用。但是，这并不是因为 MISC_CTL 的位 1 （GMET） 以某种方式启用了报告 SS 位;
    相反，除非 GMET 也存在，否则 Hyper-V 永远不会使用 CET。即使 gmet=0 也可重现 WARN，但需要对 kvm-unit-tests 的 cet.c 测试用例进行一些黑客攻击，以确保首次访问影子堆栈时触发页面错误。（CVE-2026-99120）

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

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

  - KVM：x86/mmu：處理在 #NPF 退出代碼中設定的 SS 位元 從 Windows 11 執行 Hyper-V 時，KVM 會看到針對陰影 NPT 產生的巢狀頁面錯誤碼中設定的 SS 位元。AMD 手冊不清楚何時設定 SS，包括當 VMCB 的MISC_CTL欄位中未設定 SupervisorShadowStackEn（位元 6）時是否可以設定。然而，意外的 SS 位元會導致 permission_fault（） 中的越界存取，視為 WARN 或 UBSAN 報告： 核心：UBSAN： array-index-out-of-bounds 在 arch/x86/kvm/mmu.h：225：27 核心：索引 34 超出類型「u16 [16]」的範圍（在此情況下，頁面錯誤錯誤代碼為 34*2=0x44，即 SS|U;報告顯示 SS|U|W 也發生）。透過丟棄 SS 和 （使用 WARN） 不在 permission_fault（） 預期接收的位元中的任何位元，來修正對未知錯誤碼的處理。同時，鑑於硬體何時設定 SS 的不確定性，請在建構錯誤的錯誤碼時遵循處理器的行為，並保留傳遞給 FNAME（walk_addr_generic） 的 SS 位。雖然這種行為令人驚訝，但 Hyper-V 有可能預期它（Hyper-V 甚至不會啟用 CET，除非它找到 MBEC/GMET！），因此在將故障反映到 L1 時保留信息，而不是無條件地丟棄它。Bisection 顯示這種情況從提交 687ee95c1b6d （KVM： nSVM：為客體啟用 GMET） 開始發生，即使 SHSTK 自 Linux 6.18以來可供客體使用。然而，這並不是因為 MISC_CTL 位元 1 （GMET） 以某種方式能夠報告 SS 位元;
    相反，這只是 Hyper-V 從不使用 CET，除非 GMET 也存在。即使使用 gmet=0，WARN 也是可重現的，但對 kvm-unit-tests 的 cet.c 測試用例進行一些黑客攻擊，以確保首次訪問影子堆棧會觸發頁面錯誤。（CVE-2026-99120）

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

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

  - KVM:x86/mmu:#NPF 終了コードで設定されている SS ビットに対処します。Windows 11 から Hyper-V を実行するときに、KVM は、シャドウ NPT 用に生成されたネスト化ページ障害エラーコードに SS ビットが設定されているのを認識します。AMD マニュアルには、VMCB の MISC_CTL フィールドに SupervisorShadowStackEn(ビット 6)が設定されていない場合に SS を設定できるかどうかなど、SS がいつ設定されるかについて不明瞭です。それにもかかわらず、予期しないSSビットにより、WARNまたはUBSANとして表示されるpermission_fault()で領域外アクセスが発生します。レポート:カーネル:UBSAN:arch/x86/kvm/mmu.h:225:27の array-index-out-of-bounds カーネル:インデックス34がタイプ「u16 [16]」の範囲外です(この場合、ページフォールトエラーコードは34*2=0x44、つまりSS|U;レポートには、SS|U|Wも発生)。SS をドロップし、(警告とともに)permission_fault() が受信すると予測するものにないビットをドロップすることで、不明なエラーコードの処理を修正します。同時に、ハードウェアがSSを設定するタイミングが不確実であるため、障害のエラーコードを構築するときにプロセッサーの動作に従い、SSビットをFNAME(walk_addr_generic)に渡されるものとして保持します。動作は驚くべきものですが、Hyper-V がそれを予期している可能性があるため (Hyper-V は MBEC/GMET を見つけない限り CET さえ有効にしません!)、障害を L1 に反映するときに無条件に情報を破棄するのではなく、情報を保持します。Bisection は、SHSTK が Linux 6.18 からゲストが利用可能であったにもかかわらず、これがコミット 687ee95c1b6d(KVM:nSVM:ゲストに対して GMET を有効化)で発生し始めたことを示しています。ただし、これは、MISC_CTL(GMET)のビット 1 が何らかの形で SS ビットのレポートを可能にするためではありません。
    むしろ、GMET も存在しない限り、Hyper-V は決して CET を使用しません。警告は gmet=0 でも再現可能です。シャドウスタックへの初回アクセスがページ障害を発生させるように、kvm-unit-tests の cet.c テストケースをいくらかハッキングすることが可能です。(CVE-2026-99120)

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

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

  - KVM: x86/mmu: Cope with the SS bit being set in #NPF exit codes When running Hyper-V from Windows 11, KVM     is seeing the SS bit set in nested page fault error codes produced for shadowed NPT. The AMD manual is     unclear about when SS is set, including whether it can be set when SupervisorShadowStackEn (bit 6) is not     set in the MISC_CTL field of the VMCB. Nevertheless, the unexpected SS bit causes out of bounds accesses     in permission_fault(), seen as either WARNs or UBSAN reports: kernel: UBSAN: array-index-out-of-bounds in     arch/x86/kvm/mmu.h:225:27 kernel: index 34 is out of range for type 'u16 [16]' (in this case, the page     fault error code is 34*2=0x44, i.e. SS|U; the report shows SS|U|W happening as well). Fix the handling of     unknown error codes by dropping SS and (with a WARN) any bits not among those that permission_fault()     expects to receive. At the same time, given the uncertainty about when hardware sets SS, follow the     processor's behavior when constructing the fault's error code, and preserve the SS bit as passed to     FNAME(walk_addr_generic). While the behavior is surprising, there's a possibility that Hyper-V expects it     (Hyper-V does not even enable CET unless it finds MBEC/GMET!), so retain the information when reflecting     the fault to L1 instead of unconditionally discarding it. Bisection shows that this started happening with     commit 687ee95c1b6d (KVM: nSVM: enable GMET for guests), even though SHSTK was available to guests since     Linux 6.18. However, this is not because bit 1 of MISC_CTL (GMET) somehow enables reporting the SS bit;
    rather, it's simply that Hyper-V never uses CET unless GMET is also present. The WARN is reproducible even     with gmet=0, with some hacking of kvm-unit-tests's cet.c testcase to ensure that the first access to the     shadow stack triggers a page fault. (CVE-2026-99120)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
373360	Linux Distros 未修补的漏洞：CVE-2026-99120	Nessus	Misc.	2026/10/28	2026/11/11	high
373360	Linux Distros 未修補弱點：CVE-2026-99120	Nessus	Misc.	2026/10/28	2026/11/11	high
373360	Linux Distros のパッチ未適用の脆弱性: CVE-2026-99120	Nessus	Misc.	2026/10/28	2026/11/11	high
381194	openSUSE 16: cluster-md-kmp-nvidia64kb / dlm-kmp-nvidia64kb / etc (openSUSE-SU-2026:22307-1)	Nessus	SuSE Local Security Checks	2026/11/14	2026/11/14	high
373360	Linux Distros Unpatched Vulnerability : CVE-2026-99120	Nessus	Misc.	2026/10/28	2026/11/11	high

偵測

搜尋 Plugin

high

high

high

high

high