There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: bpf: check_cond_jmp_op(): properly
    infer if register is null Nicholas Carlini reported a bug when verifier can incorrectly infer that a
    pointer is non-null. The bug occurs when two pointers are compared and one of them has a type w/o
    PTR_MAYBE_NULL flag, but which allows a value to be NULL at runtime. Here is an example: // `a` is
    PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED // `a` is 0 at runtime. // `b` is PTR_TO_MAP_VALUE |
    PTR_MAYBE_NULL void *a = bpf_rdonly_cast(0, 0); int *b = bpf_map_lookup_elem(...); if (a == b) *b = 42; //
    verifier does not catch null pointer dereference This happens because of a special case in
    check_cond_jmp_op(), which attempts to strip PTR_MAYBE_NULL flags from pointer types, when processing
    comparisons like `rA == rB`, if either rA or rB can't be null. The non-null property is derived based on
    the absence of PTR_MAYBE_NULL flag on rA's or rB's type. But that is not sufficient for types like
    PTR_TO_MEM, as in the example. This patch replaces type_may_be_null() call with reg_not_null(), which
    contains an allowlist of types for which absence of PTR_MAYBE_NULL actually means that the value can't be
    NULL at runtime. At the moment, the list in the reg_not_null() omits two types for which PTR_MAYBE_NULL is
    applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF. In order to remain backward compatible, and assuming that only
    comparison between pointers of the same type makes sense, this commit extends reg_not_null(). W/o such an
    extension e.g. verifier_jeq_infer_not_null/null_ptr_to_map_value fails. reg_not_null() can be extended
    further, but I deem that out of scope for the fix at hand. Explicit base_type(...) != PTR_TO_BTF_ID checks
    in the check_cond_jmp_op() can be removed with migration to reg_not_null(), but that is a behavioural
    change, as the special case would start matching for PTR_TO_BTF_ID that is also is_trusted_reg(). I omit
    the behavioural change from this commit. (CVE-2026-98134)

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

  - bpf： check_cond_jmp_op（）：正確推斷暫存器是否為 null Nicholas Carlini 報告了一個錯誤，當驗證程式可以錯誤地推斷指標為非 null 時。當比較兩個指標，其中一個指標具有沒有PTR_MAYBE_NULL旗標的類型，但允許值在執行階段為 NULL 時，就會發生此錯誤。這是一個例子： // 'a' 是 PTR_TO_MEM |MEM_RDONLY |PTR_UNTRUSTED // 'a' 在運行時為 0。'b' 是 PTR_TO_MAP_VALUE |PTR_MAYBE_NULL void *a = bpf_rdonly_cast（0， 0）;int *b = bpf_map_lookup_elem（...）;如果 （a == b） *b = 42;驗證程式不會擷取 NULL 指標解除參照 這是因為 check_cond_jmp_op（） 中的特殊情況，如果 rA 或 rB 不能為 null，則在處理 'rA == rB' 之類的比較時，它會嘗試從指標類型中剝離 PTR_MAYBE_NULL 旗標。非空屬性是根據 rA 或 rB 類型上沒有PTR_MAYBE_NULL旗標衍生而來。但這對於像 PTR_TO_MEM 這樣的類型來說是不夠的，如範例所示。此修補程式將 type_may_be_null（） 呼叫替換為 reg_not_null（），其中包含類型的允許清單，缺少PTR_MAYBE_NULL實際上意味著值在運行時不能為 NULL。目前，reg_not_null（） 中的清單省略了PTR_MAYBE_NULL適用的兩種類型：PTR_TO_XDP_SOCK 和 PTR_TO_BUF。為了保持向後相容，並假設只有相同類型的指標之間的比較才有意義，此提交會擴充 reg_not_null（）。如果沒有這樣的擴展，例如 verifier_jeq_infer_not_null/null_ptr_to_map_value 會失敗。reg_not_null（） 可以進一步擴展，但我認為這超出了手頭修復的範圍。移轉至 reg_not_null（） 時，可以移除 check_cond_jmp_op（） 中的明確 base_type（...） PTR_TO_BTF_ID檢查，但這是行為上的變更，因為特殊情況會開始比對也是 is_trusted_reg（） 的PTR_TO_BTF_ID。我省略了此提交中的行為變更。（CVE-2026-98134）

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

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

  - bpf：check_cond_jmp_op（）：正确推断寄存器是否为空 Nicholas Carlini 报告了校验器可能错误地推断指针为非 null 时的一个缺陷。当比较两个指针并且其中一个指针具有类型而没有PTR_MAYBE_NULL标记时，但运行时允许值为空时时，会发生此缺陷。这是一个例子： // 'a' 是 PTR_TO_MEM |MEM_RDONLY |PTR_UNTRUSTED // 'a' 在运行时为 0。“b”为PTR_TO_MAP_VALUE |PTR_MAYBE_NULL 无效 *a = bpf_rdonly_cast（0， 0）;int *b = bpf_map_lookup_elem（...）;如果 （a == b） *b = 42;校验器未捕获空指针取消引用 这是因为 check_cond_jmp_op（） 中的一个特殊情况，在处理“rA == rB”等比较时，如果 rA 或 rB 都不能为空，则该情况会尝试从指针类型中剥离PTR_MAYBE_NULL标记。非 null 属性是基于 rA 或 rB 类型中不存在PTR_MAYBE_NULL标记而派生的。但这对于像 PTR_TO_MEM 这样的类型来说是不够的，如示例中所示。此修补程序将 type_may_be_null（） 调用替换为 reg_not_null（），后者包含允许列表，列出缺少PTR_MAYBE_NULL的类型，实际上意味着该值在运行时不能为 NULL。目前，reg_not_null（） 中的列表忽略了两种适用PTR_MAYBE_NULL类型：PTR_TO_XDP_SOCK 和 PTR_TO_BUF。为了保持向后兼容，并假设只有相同类型的指针之间的比较才有意义，此提交扩展了 reg_not_null（）。无此类扩展，例如 verifier_jeq_infer_not_null/null_ptr_to_map_value失败。reg_not_null（） 可以进一步扩展，但我认为这超出了手头的补丁的范围。迁移到 reg_not_null（） 可删除 check_cond_jmp_op（） 中的显式 base_type（...） ！= PTR_TO_BTF_ID检查，但这是一种行为更改，因为特殊情况将开始匹配同为 is_trusted_reg（） 的PTR_TO_BTF_ID。我在此提交中省略行为更改。（CVE-2026-98134）

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

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

  - bpf:check_cond_jmp_op():レジスタが null であるかどうかを適切に推測します Nicholas Carlini 氏は、検証機能がポインターが null 以外であると不適切に推測できる場合のバグを報告しました。このバグは、2 つのポインターが比較され、そのうちの 1 つのポインターのタイプが PTR_MAYBE_NULL フラグなしであるが、実行時に値を NULL にできる場合に発生します。以下に例を示します: // 'a' は PTR_TO_MEM |MEM_RDONLY |PTR_UNTRUSTED // 「a」はランタイムで 0 です。「b」はPTR_TO_MAP_VALUE |PTR_MAYBE_NULL 無効 *a = bpf_rdonly_cast(0, 0);int *b = bpf_map_lookup_elem(...);(a == b) * b = 42の場合;検証機能が NULL ポインターデリファレンスをキャッチしません これは check_cond_jmp_op() の特殊なケースによるものです。rA または rB のいずれかが null にできない場合、「rA == rB」といった比較を処理する際に、ポインタータイプから PTR_MAYBE_NULL フラグのストリップを試みます。非 null プロパティは、rA または rB の型にフラグPTR_MAYBE_NULLないことに基づいて派生します。ただし、例のように PTR_TO_MEM のような型ではこれでは十分ではありません。このパッチは、type_may_be_null()呼び出しをreg_not_null()に置き換えます。()には、PTR_MAYBE_NULLがないということは実行時に値をNULLにできないことを意味する型の許可リストが含まれています。現時点では、reg_not_null()のリストでは、PTR_MAYBE_NULLが適用される2つのタイプ(PTR_TO_XDP_SOCKとPTR_TO_BUF)が省略されています。下位互換性を維持し、同じ型のポインター間の比較のみが意味があると仮定するために、このコミットは reg_not_null() を拡張します。そのような拡張がない場合、たとえば verifier_jeq_infer_not_null/null_ptr_to_map_value が失敗します。reg_not_null()はさらに拡張できますが、私はそれが当面の修正の範囲外だと考えています。check_cond_jmp_op() での明示的な base_type(...) != PTR_TO_BTF_ID チェックは、reg_not_null() への移行で削除できますが、これは動作の変更です。特殊なケースでは、同じく is_trusted_reg() である PTR_TO_BTF_ID に対して一致が開始されるためです。このコミットからは動作の変更を省略します。(CVE-2026-98134)

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

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

  - bpf: check_cond_jmp_op(): properly infer if register is null Nicholas Carlini reported a bug when verifier     can incorrectly infer that a pointer is non-null. The bug occurs when two pointers are compared and one of     them has a type w/o PTR_MAYBE_NULL flag, but which allows a value to be NULL at runtime. Here is an     example: // `a` is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED // `a` is 0 at runtime. // `b` is     PTR_TO_MAP_VALUE | PTR_MAYBE_NULL void *a = bpf_rdonly_cast(0, 0); int *b = bpf_map_lookup_elem(...); if     (a == b) *b = 42; // verifier does not catch null pointer dereference This happens because of a special     case in check_cond_jmp_op(), which attempts to strip PTR_MAYBE_NULL flags from pointer types, when     processing comparisons like `rA == rB`, if either rA or rB can't be null. The non-null property is derived     based on the absence of PTR_MAYBE_NULL flag on rA's or rB's type. But that is not sufficient for types     like PTR_TO_MEM, as in the example. This patch replaces type_may_be_null() call with reg_not_null(), which     contains an allowlist of types for which absence of PTR_MAYBE_NULL actually means that the value can't be     NULL at runtime. At the moment, the list in the reg_not_null() omits two types for which PTR_MAYBE_NULL is     applicable: PTR_TO_XDP_SOCK and PTR_TO_BUF. In order to remain backward compatible, and assuming that only     comparison between pointers of the same type makes sense, this commit extends reg_not_null(). W/o such an     extension e.g. verifier_jeq_infer_not_null/null_ptr_to_map_value fails. reg_not_null() can be extended     further, but I deem that out of scope for the fix at hand. Explicit base_type(...) != PTR_TO_BTF_ID checks     in the check_cond_jmp_op() can be removed with migration to reg_not_null(), but that is a behavioural     change, as the special case would start matching for PTR_TO_BTF_ID that is also is_trusted_reg(). I omit     the behavioural change from this commit. (CVE-2026-98134)

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

ID	Name	Product	Family	Published	Updated	Severity
474665	Chainguard: linux-desktop-7.2-bootc: security update to 7.2.7-r0	Tenable Self-Hosted Container Security	Chainguard Local Security Checks	10/16/2026	10/18/2026	medium
474665	Chainguard: linux-desktop-7.2-bootc: security update to 7.2.7-r0	Tenable Cloud Security	Chainguard Local Security Checks	10/16/2026	10/18/2026	medium
350590	Linux Distros 未修補弱點：CVE-2026-98134	Nessus	Misc.	9/25/2026	11/11/2026	medium
350590	Linux Distros 未修补的漏洞：CVE-2026-98134	Nessus	Misc.	9/25/2026	11/11/2026	medium
350590	Linux Distros のパッチ未適用の脆弱性: CVE-2026-98134	Nessus	Misc.	9/25/2026	11/11/2026	medium
377900	Amazon Linux 2023 : bpftool6.12, kernel6.12, kernel6.12-devel (ALAS2023-2026-3402)	Nessus	Amazon Linux Local Security Checks	11/9/2026	11/11/2026	high
350590	Linux Distros Unpatched Vulnerability : CVE-2026-98134	Nessus	Misc.	9/25/2026	11/11/2026	medium
376443	Ubuntu 24.04 LTS / 26.04 LTS : Linux kernel vulnerabilities (USN-8959-1)	Nessus	Ubuntu Local Security Checks	11/5/2026	11/5/2026	high

Detections

Analytics

Plugins Search

medium

medium

medium

medium

medium

high

medium

high