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.
Published: 2026-09-25
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service via Null Pointer Dereference
Action: Patch Kernel
AI Analysis

Impact

The Linux kernel’s eBPF verifier incorrectly assumes non‑nullness for certain pointer comparisons, allowing malicious BPF programs to compare a nil pointer with a valid one. Because the verifier fails to detect the null dereference, the program may write to address zero, causing a kernel crash or memory corruption. This flaw does not grant arbitrary code execution; the direct consequence is a loss of service due to a kernel panic. The vulnerability is rooted in the CWE-476 Undefined Behavior: Null Pointer Dereference category.

Affected Systems

Any Linux kernel that includes the BPF verifier before the commit that introduced the fix is potentially affected. The CVE note does not specify a kernel version range, so all builds prior to the patch are considered vulnerable. The issue is present in both vanilla Linux and all distributions that ship the affected kernel code.

Risk and Exploitability

The CVSS score of 5.5 indicates a medium severity flaw. The EPSS score is reported as <1%, suggesting a low probability of exploitation at the time of reporting, and the vulnerability is not listed in CISA’s KEV catalog. The most likely attack vector is the submission of a specially crafted BPF program to the kernel, which could trigger a null dereference and kernel panic. No publicly available exploit or evidence of exploitation exists, but an unpatched system remains at risk for denial of service attacks from attackers able to load malicious BPF programs.

Generated by OpenCVE AI on September 30, 2026 at 09:54 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade all affected Linux kernels to a release that includes the BPF verifier patch.
  • If a kernel update cannot be performed immediately, restrict or disable eBPF program loading on untrusted or privileged systems as a temporary countermeasure.
  • Consider isolating processes that load BPF or monitoring kernel logs for eBPF verification failures to detect attempted exploitation.

Generated by OpenCVE AI on September 30, 2026 at 09:54 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 15 Oct 2026 13:30:00 +0000


Thu, 08 Oct 2026 18:30:00 +0000

Type Values Removed Values Added
CPEs cpe:2.3:o:linux:linux_kernel:7.3:rc1:*:*:*:*:*:*

Tue, 29 Sep 2026 13:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-476
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.5, 'vector': 'CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Low


Fri, 25 Sep 2026 10:45:00 +0000

Type Values Removed Values Added
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.
Title bpf: check_cond_jmp_op(): properly infer if register is null
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-10-15T10:12:18.164Z

Reserved: 2026-09-25T10:25:14.319Z

Link: CVE-2026-98134

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Modified

Published: 2026-09-25T11:17:44.820

Modified: 2026-10-15T11:18:11.633

Link: CVE-2026-98134

cve-icon Redhat

Severity : Low

Publid Date: 2026-09-25T00:00:00Z

Links: CVE-2026-98134 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-09-30T10:00:17Z

Weaknesses