{
  "cveId": "CVE-2026-98134",
  "url": "https://patchblox.com/security/cve/CVE-2026-98134",
  "summary": "CVE-2026-98134 is fixed in linux on 1 platform, first by DEBIAN-CVE-2026-98134, released October 2, 2026. It is not reported as exploited. Patch Radar priority: Routine.",
  "title": "bpf: check_cond_jmp_op(): properly infer if register is null",
  "description": "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:    // \u0060a\u0060 is PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED   // \u0060a\u0060 is 0 at runtime.   // \u0060b\u0060 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 \u0060rA == rB\u0060, if either rA or rB can\u0027t be null.  The non-null property is derived based on the absence of PTR_MAYBE_NULL flag on rA\u0027s or rB\u0027s 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\u0027t 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.",
  "published": "2026-09-25T11:17:44Z",
  "severity": "Moderate",
  "cvss": 5.5,
  "cvssVector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
  "epss": 0.00155,
  "epssPercentile": 0.0464,
  "priority": "Routine",
  "priorityTier": 4,
  "exploited": false,
  "vendorExploited": false,
  "disclosed": false,
  "vendorAdvisory": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-98134",
  "fixes": [
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 13.5 (trixie)",
      "fixedVersion": "6.12.115-2",
      "fix": "DEBIAN-CVE-2026-98134",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2026-98134",
      "released": "2026-10-02T21:04:56Z"
    },
    {
      "platform": "linux",
      "product": "linux",
      "release": "Debian 14",
      "fixedVersion": "7.2.7-1",
      "fix": "DEBIAN-CVE-2026-98134",
      "url": "https://patchblox.com/security/fix/linux/debian-cve-2026-98134",
      "released": "2026-10-02T21:04:56Z"
    }
  ],
  "noFixYet": [],
  "dataAsOf": "2026-11-08T19:12:23Z",
  "attribution": {
    "text": "Data: Patchblox Patch Radar",
    "url": "https://patchblox.com/security/patch-radar",
    "terms": "https://patchblox.com/security/patch-radar/use-the-data"
  }
}