Skip to main content
VulnerabilityPublished Updated

CVE-2026-45933: Linux kernel · bpf: Preserve id of register in sync_linked_regs()

Affects Linux kernelSource CVE Database V5

0

Not known to be exploited · CVSS 7.8 High · fixed in af9e89d8dd39530c8bd14c33ddf6b502df1071b6 : patch Linux kernel soon.

Data as of 26 Oct 2026, 17:30 UTC

CVSS 3.1 base score
7.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.1% chance of exploitation in 30 days – higher than 9% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CISA SSVC
Exploitation
No evidence of active exploitation and no public proof of concept
Automatable
Attackers cannot reliably automate steps 1–4 of the kill chain
Technical impact
Total control over the software or total information disclosure

CISA SSVC assessment, 2026-10-16.

Patch
Available – fixed in af9e89d8dd39530c8bd14c33ddf6b502df1071b6, 58059335e46537de682db84984f7716c813208c4, 92a8cb1806adefb263cf096eab6705705cf7eee1 +1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 27 May 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade Linux kernel to af9e89d8dd39530c8bd14c33ddf6b502df1071b6, 58059335e46537de682db84984f7716c813208c4, 92a8cb1806adefb263cf096eab6705705cf7eee1 or 65d114b5270b62aefb820ecd6c3b7caeea8f895d.

Affected software

ProductAffectedFixed in
LinuxLinuxAffected
  • ≥ 98d7ca374ba4b39e7535613d40e159f09ca14da2, < af9e89d8dd39530c8bd14c33ddf6b502df1071b6
Fixed in
  • af9e89d8dd39530c8bd14c33ddf6b502df1071b6
LinuxLinuxAffected
  • ≥ 98d7ca374ba4b39e7535613d40e159f09ca14da2, < 58059335e46537de682db84984f7716c813208c4
Fixed in
  • 58059335e46537de682db84984f7716c813208c4
LinuxLinuxAffected
  • ≥ 98d7ca374ba4b39e7535613d40e159f09ca14da2, < 92a8cb1806adefb263cf096eab6705705cf7eee1
Fixed in
  • 92a8cb1806adefb263cf096eab6705705cf7eee1
LinuxLinuxAffected
  • ≥ 98d7ca374ba4b39e7535613d40e159f09ca14da2, < 65d114b5270b62aefb820ecd6c3b7caeea8f895d
Fixed in
  • 65d114b5270b62aefb820ecd6c3b7caeea8f895d
LinuxLinuxAffected
  • =6.11
Fixed in–

Description

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.

References

Community reviews

Loading reviews…