Description
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:

1. 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.

2. 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().

3. 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.

4. 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:

1. sync var_off and r32 before the snapshot so they match, or
2. 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().
Published: 2026-09-25
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: BPF verifier bounds‑check bypass
Action: Patch
AI Analysis

Impact

A flaw in the Linux kernel BPF verifier causes inconsistent register bounds tracking during speculative pointer arithmetic, leading to a REG INVARIANTS VIOLATION warning. The bug is triggered when an unprivileged user loads a carefully crafted BPF program that performs a pointer addition followed by data movement; the verifier snapshots the state mid‑execution, causing the bounds check to fail. The current description does not indicate that this results in memory corruption or privilege escalation, only that the verifier generates a warning and may reject the program.

Affected Systems

The vulnerability affects the Linux kernel, specifically the BPF subsystem that verifies byte‑code programs. All kernel releases incorporating the BPF verifier before the patch that resolves the bounds‑tracking inconsistency are potentially impacted; exact version ranges are not specified in the advisory.

Risk and Exploitability

The CVSS score of 5.5 signifies moderate severity. The EPSS score of less than 1% indicates a very low probability of exploitation. The flaw is not listed in CISA’s KEV catalog. At present no publicly documented exploit exists; the primary impact is that an attacker can cause verification failures or denial of service of BPF programs by crafting a payload that exercise the specific verifier path. Achieving exploitation would require knowledge of the BPF byte‑code format and the ability to deliver a program that triggers the inconsistent state.

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

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Apply a patched Linux kernel that incorporates the commit fixing the BPF verifier bounds‑tracking bug
  • If upgrading the kernel immediately is not possible, disable unprivileged BPF program loading or enforce a restrictive BPF policy to limit operations that involve pointer arithmetic
  • Monitor system logs for verifier warnings indicating REG INVARIANTS VIOLATION and investigate any unexpected BPF activity

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

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DLA Debian DLA DLA-4817-1 linux-6.12 security update
Debian DSA Debian DSA DSA-6528-1 linux security update
History

Wed, 21 Oct 2026 20:30:00 +0000

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

Wed, 30 Sep 2026 09:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-20

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

Type Values Removed Values Added
Weaknesses CWE-617
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

Moderate


Fri, 25 Sep 2026 12:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-20

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: 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: 1. 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. 2. 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(). 3. 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. 4. 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: 1. sync var_off and r32 before the snapshot so they match, or 2. 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().
Title bpf: Fix REG INVARIANTS VIOLATION on speculative pointer arithmetic
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-19T09:14:44.471Z

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

Link: CVE-2026-98151

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

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

Modified: 2026-10-21T20:19:50.470

Link: CVE-2026-98151

cve-icon Redhat

Severity : Moderate

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

Links: CVE-2026-98151 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-09-30T13:15:19Z

Weaknesses