In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix unsound scalar forking in maybe_fork_scalars() for BPF_OR
maybe_fork_scalars() is called for both BPF_AND and BPF_OR when the
source operand is a constant. When dst has signed range [-1, 0], it
forks the verifier state: the pushed path gets dst = 0, the current
path gets dst = -1.
For BPF_AND this is correct: 0 & K == 0.
For BPF_OR this is wrong: 0 | K == K, not 0.
The pushed path therefore tracks dst as 0 when the runtime value is K,
producing an exploitable verifier/runtime divergence that allows
out-of-bounds map access.
Fix this by passing env->insn_idx (instead of env->insn_idx + 1) to
push_stack(), so the pushed path re-executes the ALU instruction with
dst = 0 and naturally computes the correct result for any opcode.
bpf: Fix unsound scalar forking in maybe_fork_scalars() for BPF_OR
maybe_fork_scalars() is called for both BPF_AND and BPF_OR when the
source operand is a constant. When dst has signed range [-1, 0], it
forks the verifier state: the pushed path gets dst = 0, the current
path gets dst = -1.
For BPF_AND this is correct: 0 & K == 0.
For BPF_OR this is wrong: 0 | K == K, not 0.
The pushed path therefore tracks dst as 0 when the runtime value is K,
producing an exploitable verifier/runtime divergence that allows
out-of-bounds map access.
Fix this by passing env->insn_idx (instead of env->insn_idx + 1) to
push_stack(), so the pushed path re-executes the ALU instruction with
dst = 0 and naturally computes the correct result for any opcode.
Advisories
| Source | ID | Title |
|---|---|---|
Ubuntu USN |
USN-8567-1 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8574-1 | Linux kernel (GCP FIPS) vulnerabilities |
Ubuntu USN |
USN-8574-2 | Linux kernel vulnerabilities |
Ubuntu USN |
USN-8595-1 | Linux kernel (Oracle) vulnerabilities |
Ubuntu USN |
USN-8596-1 | Linux kernel (NVIDIA) vulnerabilities |
Ubuntu USN |
USN-8595-2 | Linux kernel (AWS) vulnerabilities |
Ubuntu USN |
USN-8608-1 | Linux kernel (Azure FIPS) vulnerabilities |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Wed, 20 May 2026 16:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-125 |
Mon, 27 Apr 2026 14:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
cvssV3_1
|
Mon, 13 Apr 2026 12:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Weaknesses | CWE-131 | |
| References |
|
Sun, 12 Apr 2026 06:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In the Linux kernel, the following vulnerability has been resolved: bpf: Fix unsound scalar forking in maybe_fork_scalars() for BPF_OR maybe_fork_scalars() is called for both BPF_AND and BPF_OR when the source operand is a constant. When dst has signed range [-1, 0], it forks the verifier state: the pushed path gets dst = 0, the current path gets dst = -1. For BPF_AND this is correct: 0 & K == 0. For BPF_OR this is wrong: 0 | K == K, not 0. The pushed path therefore tracks dst as 0 when the runtime value is K, producing an exploitable verifier/runtime divergence that allows out-of-bounds map access. Fix this by passing env->insn_idx (instead of env->insn_idx + 1) to push_stack(), so the pushed path re-executes the ALU instruction with dst = 0 and naturally computes the correct result for any opcode. | |
| Title | bpf: Fix unsound scalar forking in maybe_fork_scalars() for BPF_OR | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-05-11T22:08:13.825Z
Reserved: 2026-03-09T15:48:24.087Z
Link: CVE-2026-31413
No data.
Status : Analyzed
Published: 2026-04-12T06:16:20.050
Modified: 2026-06-17T10:33:40.053
Link: CVE-2026-31413
OpenCVE Enrichment
Updated: 2026-05-20T18:15:26Z
Ubuntu USN