VYPR
Unrated severityNVD Advisory· Published Nov 12, 2025· Updated Apr 15, 2026

CVE-2025-40169

CVE-2025-40169

Description

In the Linux kernel, the following vulnerability has been resolved:

bpf: Reject negative offsets for ALU ops

When verifying BPF programs, the check_alu_op() function validates instructions with ALU operations. The 'offset' field in these instructions is a signed 16-bit integer.

The existing check 'insn->off > 1' was intended to ensure the offset is either 0, or 1 for BPF_MOD/BPF_DIV. However, because 'insn->off' is signed, this check incorrectly accepts all negative values (e.g., -1).

This commit tightens the validation by changing the condition to '(insn->off != 0 && insn->off != 1)'. This ensures that any value other than the explicitly permitted 0 and 1 is rejected, hardening the verifier against malformed BPF programs.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

BPF verifier ALU operations incorrectly accepted negative offsets, potentially allowing verifier bypass; tightened validation to reject non-zero and non-one offsets.

Root

Cause

The check_alu_op() function in the BPF verifier validates ALU instruction offsets. The offset field is a signed 16-bit integer. The original check insn->off > 1 allowed negative values because signed comparison accepts them. This flaw could permit malformed BPF programs with negative offsets to bypass verification [1].

Exploitation

Exploitation requires the ability to load custom BPF programs, typically requiring privileged access (CAP_BPF or root). An attacker could craft a BPF instruction with a negative offset that passes the flawed check, potentially leading to out-of-bounds memory access or other undefined behavior.

Impact

Successful exploitation could allow an attacker to bypass the BPF verifier's safety checks, potentially leading to arbitrary memory read/write, privilege escalation, or denial of service.

Mitigation

The fix changes the condition to insn->off != 0 && insn->off != 1, rejecting any offset other than 0 or 1. This hardening is applied in the Linux kernel stable tree [1][2].

AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2
  • Linux/Kernelinferred2 versions
    (expand)+ 1 more
    • (no CPE)
    • (no CPE)

Patches

4

Vulnerability mechanics

Root cause

"Signed/unsigned comparison bug in check_alu_op() allows negative offset values to bypass validation."

Attack vector

An attacker who can load a crafted BPF program into the kernel can supply an ALU instruction with a negative offset (e.g., -1). The check `insn->off > 1` treats the signed 16-bit offset as signed, so negative values pass the check even though they are not 0 or 1. This can cause the verifier to accept malformed instructions that may lead to undefined behavior during program execution.

Affected code

The vulnerability is in the `check_alu_op()` function within the BPF verifier. The faulty check `insn->off > 1` uses signed comparison on the signed 16-bit `offset` field of an ALU instruction, allowing negative values to bypass validation.

What the fix does

The patch changes the condition from `insn->off > 1` to `(insn->off != 0 && insn->off != 1)` in check_alu_op(). The original check relied on signed comparison, which incorrectly accepted all negative values. The new check explicitly tests for only the two permitted values (0 and 1), rejecting any other value including negative offsets. This closes the signed/unsigned mismatch and hardens the verifier against malformed BPF programs.

Preconditions

  • authAttacker must have the ability to load BPF programs into the kernel (requires CAP_BPF or equivalent privileges)
  • inputAttacker must craft a BPF program containing an ALU instruction with a negative offset value

Generated on May 18, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

4

News mentions

0

No linked articles in our index yet.