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: n/a
EPSS: n/a
KEV: No
Impact: Potential Kernel Denial of Service via Null Pointer Dereference
Action: Update Kernel
AI Analysis

Impact

The defect lies in the Linux kernel’s eBPF verifier, which can incorrectly assume that a pointer is non‑null when verifying BPF programs. An attacker can supply a malicious BPF bytecode that performs a comparison between two pointers, one of which is actually null at runtime. Because the verifier fails to notice this, the program may dereference a null pointer, leading to a kernel crash or memory corruption. This flaw does not immediately grant arbitrary code execution, but it can cause loss‑of‑service or provide an avenue for privilege escalation if the crash is exploited in a wider context.

Affected Systems

Any system running a Linux kernel with the BPF verifier component is potentially affected. No specific kernel version range is provided, so all builds prior to the commit that introduced the fix are included.

Risk and Exploitability

The CVSS score is not provided, and there is no EPSS data; the vulnerability is not listed in CISA’s KEV catalog. The most likely attack vector is the submission of a crafted BPF program to the kernel, a privilege that requires EXECVE‑level access or root privileges. Because the flaw is introduced during verification, an attacker cannot directly execute code, but the verifier’s failure can lead to a null pointer dereference and a subsequent kernel panic – a moderate to high severity impact if exploitation is possible. The lack of exploitation evidence and the absence of a public exploit suggest that the immediate risk is lower, but an unpatched kernel remains vulnerable to denial of service attacks.

Generated by OpenCVE AI on September 25, 2026 at 12:23 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade all affected Linux kernels to the latest stable release containing the BPF verifier fix.
  • Ensure that all servers and devices in the deployment are updated to the patched kernel version in a timely manner.
  • If an immediate kernel update is not possible, restrict the use of eBPF programs or disable eBPF loading on untrusted systems as a temporary countermeasure.

Generated by OpenCVE AI on September 25, 2026 at 12:23 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

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-09-25T10:36:12.919Z

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

Link: CVE-2026-98134

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

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

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

Link: CVE-2026-98134

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-25T13:30:18Z

Weaknesses

No weakness.