Reference page — cumulative record through Monday, October 19, 2026 UTC. Reference pages update as the archive grows; only dated daily editions are immutable pages of record.
CVE-2026-98134
Linux Linux — bpf: check_cond_jmp_op(): properly infer if register is null
AV AC PR UI S C I A CVSS EPSS %ile KEV
L L L N U N N H 5.5 .0012 1.8 —
AFFECTED
Product Versions Fixed
Linux befae75856ab406a3f3fab2aa2118cf3b2dfe3e6 – —
Linux 6.2 – 6.18.57
TIMELINE
Sep 25 Reserved by Linux
Sep 25 Published (CNA: Linux)
Oct 8 ENRICHED — CVE-2026-98134 (Linux). Received CVSS 5.5 and CPE data from NVD.
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.
Lifecycle
Complete event history — 3 events, chronological
| Date | Event | Detail |
| September 25, 2026 | Reserved | Reserved by Linux |
| September 25, 2026 | Published | Published (CNA: Linux) |
| October 8, 2026 | ENRICHED | ENRICHED — CVE-2026-98134 (Linux). Received CVSS 5.5 and CPE data from NVD. |
Affected
Affected products and packages — 2 rows
| Vendor | Product / Package | Ecosystem | Version introduced | Fixed |
| Linux | Linux | — | befae75856ab406a3f3fab2aa2118cf3b2dfe3e6 | — |
| Linux | Linux | — | 6.2 | 6.18.57 |
About this page
This is a reference page, not a dated page of record. It assembles the complete lifecycle of CVE-2026-98134 from the CVE Program record, NVD enrichment, the CISA KEV catalog, EPSS, and OSV advisories. The box score's numbers (CVSS, EPSS, KEV status) are current as of Monday, October 19, 2026 UTC and are re-derived as the archive grows; only dated daily editions are immutable pages of record. The authoritative source for this identifier is cve.org.