CVE-2026-45933
published 2026-05-27CVE-2026-45933: 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…
PriorityP340high7.8CVSS 3.1
AVLACLPRLUINSUCHIHAH
EPSS
0.18%
7.5th percentile
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+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,
Affected
9 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| linux | linux | — | — |
| linux | linux | >= 98d7ca374ba4b39e7535613d40e159f09ca14da2 < 58059335e46537de682db84984f7716c813208c4 | 58059335e46537de682db84984f7716c813208c4 |
| linux | linux | >= 98d7ca374ba4b39e7535613d40e159f09ca14da2 < 92a8cb1806adefb263cf096eab6705705cf7eee1 | 92a8cb1806adefb263cf096eab6705705cf7eee1 |
| linux | linux | >= 98d7ca374ba4b39e7535613d40e159f09ca14da2 < 65d114b5270b62aefb820ecd6c3b7caeea8f895d | 65d114b5270b62aefb820ecd6c3b7caeea8f895d |
| linux | linux | >= 98d7ca374ba4b39e7535613d40e159f09ca14da2 < af9e89d8dd39530c8bd14c33ddf6b502df1071b6 | af9e89d8dd39530c8bd14c33ddf6b502df1071b6 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 6.11 < 6.12.75 | 6.12.75 |
| linux | linux_kernel | >= 6.13 < 6.18.14 | 6.18.14 |
| linux | linux_kernel | >= 6.19 < 6.19.4 | 6.19.4 |
CVSS provenance
nvdv3.17.8HIGHCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vendor_redhat5.5LOW
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: bpf: Preserve id of register in sync_linked_regs()
vendor_redhat·2026-05-27·CVSS 5.5
CVE-2026-45933 [LOW] CWE-911 kernel: bpf: Preserve id of register in sync_linked_regs()
kernel: bpf: Preserve id of register in sync_linked_regs()
A flaw was found in the Linux kernel's BPF (Berkeley Packet Filter) verifier. The `sync_linked_regs()` function fails to preserve the register ID during bounds propagation, which can lead to incorrect register state. This issue may allow a local attacker to trigger a 'division by zero' error, resulting in a denial of service.
Package: kernel (Red Hat Enterprise Linux 10) - Fix deferred
Package: kernel (Red Hat Enterprise Linux 6) - Not affected
Package: kernel (Red Hat Enterprise Linux 7) - Not affected
Package: kernel-rt (Red Hat Enterprise Linux 7) - Not affected
Package: kernel (Red Hat Enterprise Linux 8) - Not affected
Package: kernel-rt (Red Hat Enterprise Linux 8) - Not affected
Package: kernel (Red Hat Enterprise Li
VulDB
Linux Kernel up to 6.12.74/6.18.13/6.19.3 sync_linked_regs random values
vuldb·2026-06-25·CVSS 7.8
CVE-2026-45933 [HIGH] Linux Kernel up to 6.12.74/6.18.13/6.19.3 sync_linked_regs random values
A vulnerability classified as critical was found in Linux Kernel up to 6.12.74/6.18.13/6.19.3. Impacted is the function sync_linked_regs. Executing a manipulation can lead to insufficiently random values.
The identification of this vulnerability is CVE-2026-45933. The attack needs to be done within the local network. There is no exploit available.
Upgrading the affected component is advised.
GHSA
GHSA-5q5p-j26x-cm3f: In the Linux kernel, the following vulnerability has been resolved:
bpf: Preserve id of register in sync_linked_regs()
sync_linked_regs() copies the
ghsa_unreviewed·2026-05-27
CVE-2026-45933 GHSA-5q5p-j26x-cm3f: In the Linux kernel, the following vulnerability has been resolved:
bpf: Preserve id of register in sync_linked_regs()
sync_linked_regs() copies the
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 ne
No detection rules found.
No public exploits indexed.
2026-05-27
Published