# CVE-2026-98134: bpf: check_cond_jmp_op(): properly infer if register is null

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.

- Web page: https://patchblox.com/security/cve/CVE-2026-98134
- Priority: Routine
- CVSS: 5.5 (Moderate)
- EPSS: 0.0016
- CISA KEV: not listed
- Exploited (vendor report): no
- Publicly disclosed: no
- Published: Sep 25, 2026
- Vendor advisory: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-98134

## 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:    // `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.

## Where it's fixed

| Platform | Product | Fixed in | Fix | Released |
|---|---|---|---|---|
| Linux | linux Debian 13.5 (trixie) | 6.12.115-2 | [DEBIAN-CVE-2026-98134](https://patchblox.com/security/data/fix/linux/debian-cve-2026-98134.md) | Oct 2, 2026 |
| Linux | linux Debian 14 | 7.2.7-1 | [DEBIAN-CVE-2026-98134](https://patchblox.com/security/data/fix/linux/debian-cve-2026-98134.md) | Oct 2, 2026 |

---

Data as of 2026-11-08T19:12:23Z UTC. Source: Patchblox Patch Radar (https://patchblox.com/security/patch-radar). Patchblox finds out-of-date software on Windows, macOS and Linux and updates it through release rings: https://patchblox.com/demo

Free to use with attribution: show "Data: Patchblox Patch Radar" with a link to https://patchblox.com/security/patch-radar. Terms, including what needs a written agreement: https://patchblox.com/security/patch-radar/use-the-data

Product names, logos and trademarks shown on Patch Radar belong to their respective owners. They are used only to identify the software each security fix applies to and to help readers find their platform. Their use does not imply any affiliation with, or endorsement by, those owners, and Patchblox is not affiliated with any of them.