Skip to main content

Linux Kernel EUVDEUVD-2026-32217

| CVE-2026-45933 HIGH
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-5q5p-j26x-cm3f
Linux Information Disclosure
High
Disputed · 7.8 Vendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Share

Severity by source

Sources disagree (Low–High)
Vendor (416baaa9-dc9f-4396-8d5f-8c081fb06d67) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
SUSE
HIGH
qualitative
Red Hat
5.5 LOW
qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: 416baaa9-dc9f-4396-8d5f-8c081fb06d67

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
May 30, 2026 - 11:29 vuln.today
CVSS changed
May 30, 2026 - 11:22 NVD
7.8 (HIGH)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:17 nvd
UNKNOWN (no severity yet)
CVE Published
May 27, 2026 - 14:17 nvd
HIGH 7.8

DescriptionCVE.org

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

bpf: Preserve id of register in sync_linked_regs()

sync_linked_regs() copies the id of known_reg to reg when propagating bounds of known_reg to reg using the off of known_reg, but when known_reg was linked to reg like:

known_reg = reg ; both known_reg and reg get same id known_reg += 4 ; known_reg gets off = 4, and its id gets BPF_ADD_CONST

now when a call to sync_linked_regs() happens, let's say with the following:

if known_reg >= 10 goto pc+2

known_reg's new bounds are propagated to reg but now reg gets BPF_ADD_CONST from the copy.

This means if another link to reg is created like:

another_reg = reg ; another_reg should get the id of reg but assign_scalar_id_before_mov() sees BPF_ADD_CONST on reg and assigns a new id to it.

As reg has a new id now, known_reg's link to reg is broken. If we find new bounds for known_reg, they will not be propagated to reg.

This can be seen in the selftest added in the next commit:

0: (85) call bpf_get_prandom_u32#7 ; R0=scalar() 1: (57) r0 &= 255 ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) 2: (bf) r1 = r0 ; R0=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) R1=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,var_off=(0x0; 0xff)) 3: (07) r1 += 4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=4,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 4: (a5) if r1 < 0xa goto pc+4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=10,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 5: (bf) r2 = r0 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) R2=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=255) 6: (a5) if r1 < 0xe goto pc+2 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=14,smax=umax=smax32=umax32=259,var_off=(0x0; 0x1ff)) 7: (35) if r0 >= 0xa goto pc+1 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=9,var_off=(0x0; 0xf)) 8: (37) r0 /= 0 div by zero

When 4 is verified, r1's bounds are propagated to r0 but r0 also gets BPF_ADD_CONST (bug). When 5 is verified, r0 gets a new id (2) and its link with r1 is broken.

After 6 we know r1 has bounds [14, 259] and therefore r0 should have bounds [10, 255], therefore the branch at 7 is always taken. But because r0's id was changed to 2, r1's new bounds are not propagated to r0. The verifier still thinks r0 has bounds [6, 255] before 7 and execution can reach div by zero.

Fix this by preserving id in sync_linked_regs() like off and subreg_def.

AnalysisAI

Local privilege escalation potential in the Linux kernel BPF verifier (introduced in 6.11+ commit 98d7ca374ba4) arises from sync_linked_regs() failing to preserve register IDs when propagating bounds, breaking linked-register tracking and allowing crafted eBPF programs to bypass the verifier's range analysis. EPSS is very low (0.02%) and the issue is not in CISA KEV, but the BPF verifier is a historically high-value local attack surface, and upstream patches landed in 6.12.75, 6.18.14, and 6.19.4. No public exploit identified at time of analysis.

Technical ContextAI

The bug lives in the eBPF verifier (kernel/bpf/verifier.c), the static analyzer that proves safety of in-kernel BPF programs before JIT/execution. sync_linked_regs() is used to propagate refined scalar bounds between registers that share an id (i.e., were derived from each other via mov), using a stored offset and a BPF_ADD_CONST flag. The defect: when propagating bounds from a known_reg that has BPF_ADD_CONST set, the destination register inherits that flag along with the id copy, which then causes assign_scalar_id_before_mov() on a subsequent r2 = r0 to allocate a fresh id, severing the original link. The verifier therefore retains stale, wider bounds for a register that a real execution would never satisfy - in the reproducer this lets a div-by-zero (and, more generally, out-of-range arithmetic) survive verification. Root cause class is incorrect state tracking in a verifier (a CWE-682/CWE-697-style logic error); CWE was not assigned by NVD. Affected commits cluster around 98d7ca374ba4 which introduced the linked-register bookkeeping in 6.11.

RemediationAI

Vendor-released patch: upgrade to Linux 6.12.75, 6.18.14, 6.19.4, or later stable release on the appropriate branch, which carry the fix preserving the register id in sync_linked_regs() alongside off and subreg_def (commits 58059335e465, 92a8cb1806ad, af9e89d8dd39, 65d114b5270b at https://git.kernel.org/stable/c/58059335e46537de682db84984f7716c813208c4). Where immediate patching is not possible, the most effective compensating control is to disable unprivileged BPF by setting kernel.unprivileged_bpf_disabled=1 (or =2) via sysctl and persisting it in /etc/sysctl.d/, which forces CAP_BPF/CAP_SYS_ADMIN for program loading and eliminates the attack path for ordinary users - the trade-off is breaking any application (some observability or networking agents) that relies on unprivileged BPF. In container environments, audit and remove CAP_BPF, CAP_SYS_ADMIN, and CAP_PERFMON from workloads that do not strictly require them, and prefer seccomp profiles that deny the bpf() syscall for untrusted tenants; the side effect is reduced functionality for sidecars or runtimes that legitimately load BPF (e.g., Cilium, bpftrace). Distribution backports should be tracked via the vendor advisories linked from https://nvd.nist.gov/vuln/detail/CVE-2026-45933.

Same technique Information Disclosure

View all
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

SUSE

Severity: High
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

EUVD-2026-32217 vulnerability details – vuln.today
Back

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