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

  - bpf：根據靜態暫存器活躍度分析推斷zext_dst如執行緒 [1] 中所述，驗證程式的 32 位元作業零擴充邏輯已中斷。此邏輯負責 s390 架構上 32 位元作業的正確語意。根據 BPF 語義，操作「w1 += 1」應該將零擴展暫存器「r1」的上半部分。在 s390 上，JIT 依賴驗證程式在這類作業之前發出明確的零副檔名。驗證程式會嘗試藉由追蹤是否曾經使用過 64 位暫存器的上半部，將插入的零延伸模組數量降到最低。
    以前，此類追蹤的工作原理如下： - bpf_reg_state->subreg_def 欄位由 do_check_insn（） 為每個定義暫存器下半部分而不是上半部分的操作設定。- 每當讀取整個暫存器的作業經過驗證時，驗證程式都會檢查暫存器的subreg_def，並透過呼叫 mark_insn_zext（） 函式將 bpf_insn_aux_data->zext_dst 旗標設為 true。- 驗證完成後，特殊傳遞 bpf_opt_subreg_zext_lo32_rnd_hi32（） 透過新增明確零副檔名來擴充 32 位元作業，並將 bpf_insn_aux_data->zext_dst 設為 true。請注意，上述邏輯依賴 bpf_reg_state->subreg_def，這是目前驗證程式狀態的屬性。在提交之前 [2] 發生了兩個額外的步驟： - 驗證程式在 bpf_reg_state->live 中以旗標 REG_LIVE_READ{32,64} 的形式追蹤上半邊和下半邊暫存器的活躍度。- 函數 propagate_liveness（） 稱為 mark_insn_zext（） 以傳輸有關哪些暫存器具有上半部分的知識 （因此可能需要零擴展）。提交 [2] 刪除了上述兩個步驟，因此可能出現如下情況： - 暫存器的上半部分已設定並在某些驗證路徑 P1 上使用，而暫存器恰好沒有被標記為精確。- 檢查點 C 是在處理暫存器起始設定與使用之間的某些指令時建立。- 在某些其他驗證路徑 P2 上，暫存器的上半部分未初始化，且該路徑結束時會達到檢查點 C。- 在這種情況下，暫存器在路徑 P2 上的初始化將缺少zext_dst標記，因此程式可以在暫存器的上半部分插入任意值。作為 bpf_compute_live_registers （） 分析的一部分，此提交會以靜態方式取代subreg_def zext_dst型邏輯：- 分析現在會分別追蹤暫存器上半部和下半部的使用情形。- 如果某個指令定義了 32 位元子暫存器，但不是整個暫存器，且*且*暫存器的上半部分在該指令之後處於活動狀態，則該指令會標示為zext_dst。精度有一個顯著下降：
    每當呼叫 BPF 子程式時，都會推定使用所有 64 位參數暫存器。假設這種精度下降不會造成明顯的性能損失。[1] https://lore.kernel.org/bpf/CAGKGUv=sOuqQtA1Ub-5JXfA4FPosJFYKAQE4B79cK+P1erxqtg@mail.gmail.com/ [2] commit 107e16979905 （bpf：停用並移除基於鏈結的暫存器活躍度） （CVE-2026-98869）

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

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

  - bpf：基于静态寄存器活动性分析推断zext_dst 如线程 [1] 中所报告，校验器的 32 位操作零扩展逻辑已被破坏。此逻辑负责在 s390 架构上实现 32 位操作的正确语义。根据 BPF 语义，操作“w1 += 1”应该零扩展寄存器“r1”的上半部分。在 s390 上，JIT 依赖于在此类操作之前发出显式零扩展的校验器。校验器会尝试通过跟踪是否曾经使用 64 位寄存器的上半部分，来最大程度减少插入的零扩展数。
    以前，此类跟踪的工作方式如下：- bpf_reg_state->subreg_def 字段由 do_check_insn（） 为用于定义寄存器的下半部分（而不是上半部分）的每个操作设置。- 每当验证读取整个寄存器的操作时，校验器将检查寄存器的subreg_def并通过对 mark_insn_zext（） 函数的调用将 bpf_insn_aux_data->zext_dst 标记设置为 true。- 验证完成后，特殊传递 bpf_opt_subreg_zext_lo32_rnd_hi32（） 通过添加显式零扩展将 bpf_insn_aux_data->zext_dst 设置为 true 的 32 位操作。请注意，上述逻辑依赖于 bpf_reg_state->subreg_def，后者是当前验证器状态的属性。在提交之前 [2] 发生了两个额外的步骤：- 验证器将上半寄存器和下寄存器半部的活动状态作为标记进行跟踪 bpf_reg_state->live 中的标记 REG_LIVE_READ{32,64}。- 调用 mark_insn_zext（） 的函数 propagate_liveness（） 以便传输有关哪些寄存器的上半部分处于活动状态（因此可能需要零扩展）的知识。提交 [2] 删除了上述两个步骤，因此可能出现如下情况：- 寄存器的上半部分已设置并在某些验证路径 P1 上使用，而寄存器恰好没有被标记为精确。- 检查点 C 是在处理寄存器初始化和使用之间的某些指令时创建的。- 在某些其他验证路径 P2 上，寄存器的上半部分未初始化，并且该路径在命中检查点 C 时结束。- 在此类情况下，寄存器在路径 P2 上的初始化将缺少zext_dst标记，从而可能使程序在寄存器的上半部分注入任意值。此提交将基于subreg_def的逻辑替换为静态计算zext_dst，作为 bpf_compute_live_registers（） 分析的一部分：- 分析现在可分别跟踪寄存器上半部和下半部的使用情况。- 如果某条指令定义了 32 位子寄存器，而不是整个寄存器，并且*并且* 寄存器的上半部分在该指令之后处于活动状态，则该指令被标记为zext_dst。精度有一个明显的下降：
    每当调用 BPF 子程序时，假定所有 64 位参数寄存器均已使用。假设精度的这种下降不会造成明显的性能损失。[1] https://lore.kernel.org/bpf/CAGKGUv=sOuqQtA1Ub-5JXfA4FPosJFYKAQE4B79cK+P1erxqtg@mail.gmail.com/ [2] 提交 107e16979905（bpf：禁用和删除基于寄存器链的活动性）（CVE-2026-98869）

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

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

  - bpf:静的レジスタの活性分析に基づいてzext_dstを推論します スレッド [1] で報告されているように、検証機能の 32 ビット操作のゼロ拡張ロジックは破損しています。このロジックは、s390アーキテクチャの32ビット操作の正しいセマンティクスを担当します。BPF セマンティクスによれば、演算「w1 += 1」は、レジスター「r1」の上半分をゼロ拡張すると考えられています。s390 では、JIT は、そのような操作の前に明示的なゼロ拡張を放出する検証機能に依存します。検証機能は、64 ビットレジスターの上半分が使用されているかどうかを追跡することで、挿入されるゼロ拡張の量を最小化しようとします。
    以前は、このような追跡は次のように機能していました: - bpf_reg_state->subreg_def フィールドは、レジスタの下半分を定義するが上半分を定義する操作ごとに do_check_insn() により設定されていました。- レジスタ全体を読み取る操作が検証されるたびに、検証機能はレジスタのsubreg_defをチェックし、mark_insn_zext() 関数への呼び出しを介して bpf_insn_aux_data->zext_dst フラグを true として設定しました。- 検証の完了後、特別なパス bpf_opt_subreg_zext_lo32_rnd_hi32() は、明示的なゼロ拡張を追加することで、bpf_insn_aux_data->zext_dst を true として設定して 32 ビットの操作を拡張しました。上記のロジックは、現在の検証機能状態のプロパティである bpf_reg_state->subreg_def に依存していることに注意してください。コミット [2] の前に、さらに 2 つのステップが行われました: - 検証機能は、上レジスタと下レジスタの半分の生体を bpf_reg_state->live のフラグ REG_LIVE_READ{32,64} として追跡しました。- 関数 propagate_liveness() は、どのレジスターの上半分が生きているか (したがって、ゼロ拡張が必要になる可能性がある) ことに関する知識を転送するために mark_insn_zext() を呼び出します。コミット [2] は上記の 2 つのステップを削除したため、以下のような状況が引き起こされます: - レジスタの上半分が設定され、一部の検証パス P1 で使用されているのに、レジスタがたまたま正確としてマークされていません。- チェックポイント C は、レジスタの初期化と使用の間の何らかの命令を処理する際に作成されます。- 他の検証パス P2 では、レジスタの上半分は初期化されず、そのパスはチェックポイント C に当たって終了します。 - こうした場合、パス P2 のレジスタの初期化にはマークzext_dst欠き、プログラムがレジスタの上半分に任意の値を注入することが可能になります。このコミットは、bpf_compute_live_registers()分析の一部として、subreg_defベースのロジックを静的な計算zext_dstに置き換えます。- 分析は、レジスタの上半分と下半分の使用を別々に追跡するようになりました。- ある命令が 32 ビットのサブレジスタを定義しているが、レジスター全体を定義しておらず、レジスタの上半分がその命令の後に生きている場合、その命令はzext_dstとしてマークされます。精度の顕著な低下が 1 つあります。
    BPF サブプログラムが呼び出されるたびに、パラメーターレジスタの 64 ビットすべてが使用されていると見なされます。そのような精度の低下は、顕著なパフォーマンス低下にはならないと想定されます。[1] https://lore.kernel.org/bpf/CAGKGUv=sOuqQtA1Ub-5JXfA4FPosJFYKAQE4B79cK+P1erxqtg@mail.gmail.com/ [2] コミット 107e16979905(bpf:レジスタチェーンベースのライブネスを無効化および削除)(CVE-2026-98869)

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

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

  - bpf: Infer zext_dst based on static register liveness analysis As reported in the thread [1], the     verifier's 32-bit operations zero extension logic is broken. This logic is responsible for correct     semantics of 32-bit operations on s390 architecture. According to BPF semantics, operation `w1 += 1` is     supposed to zero extend the upper half of the register `r1`. On s390 the JIT relies on the verifier     emitting explicit zero extension before such operations. The verifier attempts to minimize the amount of     zero extensions inserted by tracking whether upper halves of the 64-bit registers are ever used.
    Previously such tracking worked as follows: - bpf_reg_state->subreg_def field was set by do_check_insn()     for each operation defining lower but not the upper halves of the register. - Whenever an operation     reading the whole register was verified, the verifier checked register's subreg_def and set     bpf_insn_aux_data->zext_dst flag as true via a call to mark_insn_zext() function. - After the verification     was complete, a special pass bpf_opt_subreg_zext_lo32_rnd_hi32() extended 32-bit operations with     bpf_insn_aux_data->zext_dst set as true by adding explicit zero extension. Note that the logic above     relies on bpf_reg_state->subreg_def, which is a property of a current verifier state. Before the commit     [2] two additional steps happened: - The verifier tracked upper and lower register halves' liveness as     flags REG_LIVE_READ{32,64} in bpf_reg_state->live. - The function propagate_liveness() called     mark_insn_zext() in order to transfer the knowledge about which registers have their upper halves alive     (and thus might require zero extension). The commit [2] removed the two steps described above, hence     making possible a situation like below: - The register's upper half is set and is used on some     verification path P1 and the register happens not to be marked as precise. - The checkpoint C is created     while processing some instruction between register initialization and usage. - On some other verification     path P2 the register's upper half is not initialized and that path ends hitting the checkpoint C. - In     such a case the register's initialization on path P2 would lack zext_dst mark, making it possible for the     program to inject an arbitrary value in the register's upper half. This commit replaces subreg_def based     logic with computing zext_dst statically, as a part of the bpf_compute_live_registers() analysis: - The     analysis now tracks usage of upper and lower halves of the registers separately. - If some instruction     defines a 32-bit subregister, but not the whole register, *and* the upper half of the register is alive     after that instruction, the instruction is marked as zext_dst. There is one notable drop in precision:
    whenever a BPF subprogram is called, all 64 bits of parameter registers are presumed to be used. The     assumption is that such a drop in precision would not inflict a noticeable performance penalty. [1]     https://lore.kernel.org/bpf/CAGKGUv=sOuqQtA1Ub-5JXfA4FPosJFYKAQE4B79cK+P1erxqtg@mail.gmail.com/ [2] commit     107e16979905 (bpf: disable and remove registers chain based liveness) (CVE-2026-98869)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
370051	Linux Distros 未修補弱點：CVE-2026-98869	Nessus	Misc.	2026/10/21	2026/10/28	high
370051	Linux Distros 未修补的漏洞：CVE-2026-98869	Nessus	Misc.	2026/10/21	2026/10/28	high
370051	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98869	Nessus	Misc.	2026/10/21	2026/10/28	high
370051	Linux Distros Unpatched Vulnerability : CVE-2026-98869	Nessus	Misc.	2026/10/21	2026/10/28	high

偵測

搜尋 Plugin

high

high

high

high