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.

Detections

Analytics

Linux Distros Unpatched Vulnerability : CVE-2026-98134

medium Nessus Plugin ID 350590

Version 1.6

Version 1.5

Version 1.4

Version 1.2

Version 1.1

Version 1.6 Oct 12, 2026, 12:19 PM CVSS metrics ("CVSSv2 score" set to 4.6) CVSS metrics ("CVSSv2 vector" set to "CVSS2#AV:L/AC:L/Au:S/C:N/I:N/A:C") CVSSv2 severity (based on CVE-2026-98134, severity increased from "Low" to "Medium") Plugin Feed: 202610121219
Version 1.5 Oct 9, 2026, 2:01 PM Detection (updated detection logic) Plugin Feed: 202610091401
Version 1.4 Oct 2, 2026, 6:07 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202610021807
Version 1.2 Sep 29, 2026, 4:08 PM Detection (updated detection logic) Plugin metadata Plugin Feed: 202609291608
Version 1.1 Sep 26, 2026, 2:30 AM New Plugin Feed: 202609260230