Skip to main content

Linux Kernel CVE-2026-98134

| EUVDEUVD-2026-86965 MEDIUM
NULL Pointer Dereference (CWE-476)
2026-09-25 Linux GHSA-pp33-9ggx-8qj6
5.5
CVSS 3.1 · NVD
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Obtain local eBPF load capability
  2. Delivery
    Craft program comparing PTR_TO_MEM and map-value pointers
  3. Exploit
    Bypass verifier null inference
  4. Execution
    Dereference NULL pointer in kernel
  5. Impact
    Kernel panic and denial of service

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A10:2025 - Mishandling of Exceptional Conditions
ASVS 5.0
V16 - Security Logging and Error Handling Null pointer safety, defensive checks
MITRE ATT&CK

1 technique across 1 tactic: Impact

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Requires local ability to load eBPF programs into the kernel - in practice CAP_BPF or CAP_SYS_ADMIN, OR a system configured to permit unprivileged eBPF (kernel.unprivileged_bpf_disabled=0). The specific trigger is a crafted eBPF program that compares two pointers where one has a type lacking the PTR_MAYBE_NULL flag but can still be NULL at runtime (e.g. a PTR_TO_MEM from bpf_rdonly_cast compared to a map-value pointer), causing the verifier to wrongly strip null-checking and allow a NULL dereference. Limiting factors: exploitation is local only (no remote vector), gated by BPF load privileges, impact is confined to a kernel crash (availability) with no code execution or data disclosure in the base vector, and affected kernels are those containing the flawed check_cond_jmp_op() inference (introduced around 6.2 per EUVD). Hosts that disable unprivileged BPF substantially reduce the exposed attacker population.

Impact

This is a genuine but moderate-priority kernel robustness flaw, not an urgent fire. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 5.5 MEDIUM) is internally consistent with the description: exploitation requires local access and some privilege (the ability to load an eBPF program), and the only impact is availability - a kernel NULL pointer dereference (CWE-476) causing a panic/crash. There is no confidentiality or integrity impact in the vector, which aligns with the described outcome of an uncaught NULL dereference rather than a controllable write primitive. The EPSS score is very low (0.16%, 4th percentile), and the CVE is NOT listed in CISA KEV, and no public exploit is referenced - all three signals agree that real-world mass exploitation is unlikely. The main nuance defenders must weigh is the privilege prerequisite: the real risk hinges almost entirely on whether unprivileged eBPF loading is permitted on the host. On hardened systems where eBPF requires CAP_BPF/CAP_SYS_ADMIN, PR:L is arguably generous and real exposure is minimal; on systems allowing unprivileged BPF, the attacker population is larger. Note the description's example references a verifier logic flaw where a NULL map-value pointer dereference is missed - this is a local DoS, consistent with A:H only. No signals conflict materially; all point to a low-to-moderate, privilege-gated local DoS.

Exploit ScenarioDerived

A local user able to load eBPF programs submits a crafted program that compares a PTR_TO_MEM pointer (which can be NULL at runtime) against a PTR_TO_MAP_VALUE pointer, defeating the verifier's incorrect non-null inference in check_cond_jmp_op(). The verifier accepts the program, which then dereferences the NULL pointer, triggering a kernel panic and denial of service. No public exploit was identified at time of analysis; exploitation requires local access and eBPF load privileges.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
No patch listed yet 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 08, 2026

A local NULL-pointer dereference in the Linux kernel's BPF verifier (CVE-2026-98134) lets a crafted eBPF program reach an unchecked NULL dereference, crashing the kernel and denying service. The flaw lives in check_cond_jmp_op(), which strips PTR_MAYBE_NULL when comparing two pointer registers based purely on the absence of that flag, an assumption that breaks for types such as PTR_TO_MEM produced by bpf_rdonly_cast(0, 0); kernels carrying the affected inference (introduced around Linux 6.2) are exposed. Exploitation requires the ability to load eBPF programs, which in practice means CAP_BPF or CAP_SYS_ADMIN, or a host with unprivileged BPF enabled, and the CVSS 3.1 vector (5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) reflects local, privilege-gated, availability-only impact with no code execution or data disclosure. There is no CISA KEV listing and no public exploit identified at time of analysis, and EPSS is low at 0.16% (4th percentile), making this a moderate-priority kernel robustness fix rather than an urgent, actively exploited threat.

RemediationAI

Vendor-released patch: upstream fixes are published as the stable commits https://git.kernel.org/stable/c/d3ef6c097ba078e1f8c7239d76a0ce8b61e75095 and https://git.kernel.org/stable/c/b55c9f019e169ed0d01394f96e172286a8b21b99, and EUVD records the fixed lines as Linux 7.2.7 and Linux 7.3-rc2; upgrade to a kernel build that contains one of those commits (or your distribution's backport of the reg_not_null() change) and reboot, since the verifier change only takes effect for a running kernel. If patching cannot be done immediately, the highest-value compensating control is to remove the attacker's ability to load eBPF programs: set kernel.unprivileged_bpf_disabled=1 (or 2, which requires explicit administrator action to re-enable) on any host that currently permits unprivileged BPF, and restrict CAP_BPF and CAP_SYS_ADMIN so that only trusted services can load programs - the trade-off being that this breaks unprivileged eBPF-based observability and some container/sandbox tooling that relies on it. Where legitimate BPF workloads must continue, confine BPF-capable processes with seccomp and/or LSM policy and treat CAP_BPF holders as highly privileged, since the flaw is reachable by any principal that can get a crafted program accepted by the verifier; there is no remote attack surface to filter and no configuration switch that specifically disables the affected comparison logic without losing legitimate pointer comparisons. Confirm exposure against your distribution's kernel advisory and watch https://nvd.nist.gov/vuln/detail/CVE-2026-98134 for updates; note that because no public exploit code has been identified, patch scheduling can be risk-based rather than emergency, but the fix should still be prioritised on multi-tenant hosts that allow BPF loading.

Affected VersionsENISA

Linux 6.2
Linux patch: 7.3-rc2
Linux patch: 7.2.7
Linux patch: 0
Linux befae75856ab406a3f3fab2aa2118cf3b2dfe3e6 <d3ef6c097ba078e1f8c7239d76a0ce8b61e75095
Linux befae75856ab406a3f3fab2aa2118cf3b2dfe3e6 <b55c9f019e169ed0d01394f96e172286a8b21b99

Affected Packages

euvd linux no fix

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The Linux BPF verifier performs static analysis of eBPF bytecode before allowing it to run, tracking register types and, for pointer types, the PTR_MAYBE_NULL flag that records whether a register could legitimately hold NULL at runtime. check_cond_jmp_op() handles conditional jumps such as 'rA == rB' and contains a special case that clears PTR_MAYBE_NULL from the compared registers' types when it concludes one side cannot be NULL. That conclusion was derived from type_may_be_null(), i.e. the simple absence of PTR_MAYBE_NULL on the register type, which is sound for some pointer classes but not for PTR_TO_MEM. In the reported trigger, 'a' is a PTR_TO_MEM | MEM_RDONLY | PTR_UNTRUSTED value that actually holds 0 at runtime (obtained via bpf_rdonly_cast(0, 0)), while 'b' is a PTR_TO_MAP_VALUE | PTR_MAYBE_NULL from bpf_map_lookup_elem(); because 'a's type lacks PTR_MAYBE_NULL, the verifier wrongly treats the comparison as proving 'b' non-NULL and permits the subsequent '*b = 42' write, producing a NULL dereference in the kernel (CWE-476). The fix replaces type_may_be_null() with a new reg_not_null() helper that uses an allowlist of register types for which the absence of PTR_MAYBE_NULL genuinely implies non-NULL at runtime, and extends that allowlist to cover PTR_TO_XDP_SOCK and PTR_TO_BUF so that existing cases such as verifier_jeq_infer_not_null/null_ptr_to_map_value continue to behave as before. The commit deliberately stops short of migrating PTR_TO_BTF_ID handling into the same path because that would change behaviour for trusted BTF_ID registers, and further broadening of reg_not_null() is left out of scope. CPE data identifies the affected component as linux:linux, with no separate BPF subsystem product to distinguish.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

NVD PRIMARY 5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI 5.5 MEDIUM

Exploitation needs local privilege to load eBPF (AV:L, PR:L), is reliably triggerable (AC:L), and only crashes the kernel (C:N/I:N/A:H).

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Red Hat 5.5 LOW

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

3
CVSS changed
Oct 08, 2026 - 18:23 NVD
5.5 (MEDIUM)
CVE Published
Sep 25, 2026 - 10:36 cve.org
UNKNOWN (no severity yet)
CVE Published
Sep 25, 2026 - 10:36 nvd
MEDIUM 5.5

DescriptionNVD

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.

Threat Intelligence Overview

EPSS Score
0.2%
Top 96% exploitable
Prevalence
Ubiquitous
Linux kernel runs on a huge fraction of servers, cloud, and devices
Data Quality
6 sources
Confidence: High

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC No
EPSS 0.2%
Patch available No
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Defer
Exploitation· derived
None
System Exposure· derived
Small
Automatable· derived
No
Human Impact· derived
Medium

Priority Score

28
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +28
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

A null pointer dereference occurs when a program attempts to access memory through a pointer that has been set to NULL (address 0x0).

Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.

Vendor StatusVendor

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy