Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain local low-privileged shell
-
DeliveryCraft BPF program with speculative pointer arithmetic
-
ExploitSubmit via bpf() syscall to verifier
-
ExecutionTrigger REG INVARIANTS VIOLATION warning
-
ImpactKernel WARN/panic denial of service
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V16 - Security Logging and Error Handling Reachable assertion handling
|
| Exploitation Conditions | Requires local ability to load eBPF programs, which in practice means unprivileged eBPF must be permitted (e.g. kernel.unprivileged_bpf_disabled=0) or the actor must already hold CAP_BPF/CAP_SYS_ADMIN - a significant limiting factor because most modern distributions ship unprivileged eBPF disabled by default. The specific trigger is a crafted BPF program performing pointer arithmetic (dst_reg += bounded scalar) on a PTR_TO_MAP_VALUE register that drives the verifier down the speculative sanitize_ptr_alu() path. Impact is bounded to a kernel WARN splat unless the system is configured with panic_on_warn, in which case it escalates to a full denial of service; there is no network vector and no confidentiality/integrity consequence. |
| Impact | All signals point to a low-to-moderate, availability-only local issue rather than a priority threat. The provided CVSS vector (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H, base 5.5 Medium) describes a locally-reachable flaw requiring low privileges, with no confidentiality or integrity impact and only availability impact - consistent with CWE-617 (reachable assertion / verifier WARN). EPSS is very low at 0.16% (4th percentile), the CVE is NOT on CISA KEV, and no public exploit code is referenced, so exploitation status is 'no public exploit identified at time of analysis'. These signals are mutually consistent (low EPSS, no KEV, local-only, availability-only) - there is no conflict suggesting hidden severity. One nuance to verify: the input Tags label this 'Information Disclosure', but the CVSS vector sets C:N and the root cause is a false-positive verifier invariant warning on a safe program, which maps to denial of service (A:H), not disclosure - treat the 'Information Disclosure' label as unreliable. Realistically this is a code-correctness/robustness fix in the eBPF verifier whose practical impact is a kernel WARN splat (crash only if panic_on_warn is set), reachable only where unprivileged eBPF is permitted. It is a legitimate fix but not an urgent, widely-exploited priority. |
| Exploit ScenarioDerived | A local unauthenticated-in-the-kernel-sense but low-privileged user on a system that permits unprivileged eBPF loads a crafted BPF program performing speculative pointer arithmetic on a PTR_TO_MAP_VALUE register. The verifier's speculative-path handling snapshots an inconsistent register state (var_off out of sync with the 32-bit range), tripping reg_bounds_sanity_check() and emitting a REG INVARIANTS VIOLATION WARN, which becomes a denial of service on kernels configured with panic_on_warn. No public exploit code is referenced in the provided data. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 21, 2026
Crafted pointer arithmetic in a BPF program can desynchronize the verifier's 64-bit var_off and 32-bit subregister bounds, triggering a REG INVARIANTS VIOLATION WARN in the Linux kernel and, on systems with panic_on_warn enabled, a local denial of service. The bug affects Linux kernel builds before the stable fixes 6.12.111, 6.18.53, 7.2.7, and 7.3-rc2, and requires local low-privileged access (CVSS PR:L) with the ability to load eBPF programs-typically unprivileged eBPF enabled or CAP_BPF/CAP_SYS_ADMIN. No public exploit identified at time of analysis; EPSS is 0.16% (4th percentile), and there is no confidentiality or integrity impact.
RemediationAI
Apply the vendor-released stable fixes: Linux 6.12.111, 6.18.53, 7.2.7, or 7.3-rc2 (or later), corresponding to the git.kernel.org stable commits 21a681526c715aebb4f918b8c131583442d1b3d8, d623a4a58bb238443505d5c2949d1182dcfc26b6, 9f9477ae73de9c5a28e8ab7000d8097b078faee4, and 150aeba624e8b7cac51c39440d7e8e1fd11de9a0; see https://nvd.nist.gov/vuln/detail/CVE-2026-98151. For the EUVD-listed Linux 6.8, confirm vendor backport status because the provided data does not identify a 6.8 fix. Where patching is delayed, set kernel.unprivileged_bpf_disabled=1 (or 2) to block unprivileged BPF program loading and restrict CAP_BPF/CAP_SYS_ADMIN, accepting that this breaks unprivileged eBPF-based observability, container networking, and sandbox tooling. Ensure kernel.panic_on_warn is not enabled on systems where a verifier WARN must not escalate to a panic, understanding that this removes a deliberate diagnostic hardening control. No public exploit identified at time of analysis.
Affected VersionsENISA
Affected Packages
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 flaw is a verifier state-consistency bug (CWE-617, reachable assertion) in the eBPF verifier's pointer arithmetic handling. For PTR_TO_MAP_VALUE, adjust_ptr_min_max_vals() computes a new offset into var_off and the 32/64-bit ranges; because pointer registers do not track 32-bit subregister bounds, __mark_reg32_unbounded() blanks r32 to the full range and reg_bounds_sync() later re-derives it. On the unprivileged path, sanitize_ptr_alu() inserts speculative masking and, via sanitize_speculative_path() -> push_stack(), snapshots register state between those two steps for the next instruction's speculative verification. The snapshot therefore carries a const var_off alongside a fully unbounded r32; when the speculative path reaches reg_bounds_sanity_check(), the mismatch trips the WARN. The fix takes approach 2: move __mark_reg32_unbounded() after sanitize_ptr_alu() so the speculative snapshot preserves the pointer's original consistent r32, while the non-speculative path still blanks and re-derives r32 as before. CPE data is wildcard (cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:*), so version identification depends on the EUVD patch ranges rather than CPE granularity. Although the feed carries an Information Disclosure tag, the assessed vector and root cause support only availability impact (C:N/I:N/A:H).
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
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Local bpf() syscall access with low privilege (eBPF load capability), deterministic trigger so AC:L, and a verifier WARN causing only availability impact (A:H), no C/I.
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
4DescriptionNVD
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic
Take the following unprivileged program as an example:
r0 = bpf_map_lookup_elem(...) /* PTR_TO_MAP_VALUE, offset 0 */ ... 14: r0 += r1 /* r1 is a bounded scalar */ 15: r9 = r0
Loading it triggers a verifier warning from reg_bounds_sanity_check():
verifier bug: REG INVARIANTS VIOLATION (alu): const subreg tnum out of sync with range bounds r64={.base=0x0, .size=0x0} r32={.base=0x0, .size=0xffffffff} var_off=(0x0, 0x0)
What happens:
- Processing insn 14 (r0 += r1) in adjust_ptr_min_max_vals(), the new
offset is computed into dst_reg's var_off and 32/64-bit ranges.
- Because pointer registers do not track 32-bit subregister bounds,
__mark_reg32_unbounded() first sets r32 to the full range; r32 is re-derived from the offset at the end of the function by reg_bounds_sync().
- On the unprivileged path, sanitize_ptr_alu() is called and, via
sanitize_speculative_path() -> push_stack(), snapshots the current register state and schedules the next instruction (insn 15) to be verified directly as a speculative path.
- That snapshot is taken between step 2 and the final reg_bounds_sync():
at this point dst_reg's var_off still holds the (const) original offset while r32 has just been blanked to the full range, i.e. the two are out of sync. When the speculative path later verifies insn 15 (r9 = r0), the inconsistent state reaches reg_bounds_sanity_check() and trips the warning.
var_off and the 32-bit range must always be consistent. There are two ways to keep the snapshot consistent:
- sync var_off and r32 before the snapshot so they match, or
- leave r32 at its original (already consistent) value and blank it
only after the snapshot.
The whole point of sanitize_ptr_alu() is to insert a harmless masking sequence that keeps the access in bounds under speculation, so the state it snapshots should faithfully represent that. Take approach 2: move __mark_reg32_unbounded() to after sanitize_ptr_alu(), so the speculative snapshot keeps the pointer's original, consistent r32. The non-speculative path is unchanged: r32 is still blanked before the offset is applied and re-derived by reg_bounds_sync().
Threat Intelligence Overview
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.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
EUVD-2026-86982
GHSA-6969-2pr3-9qx5
NVD
CVE.org
EPSS
Exploit-DB