CVE-2026-45933

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

bpf: Preserve id of register in synclinkedregs()

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

knownreg = reg ; both knownreg and reg get same id knownreg += 4 ; knownreg gets off = 4, and its id gets BPFADDCONST

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

if known_reg >= 10 goto pc+2

knownreg's new bounds are propagated to reg but now reg gets BPFADD_CONST from the copy.

This means if another link to reg is created like:

anotherreg = reg ; anotherreg should get the id of reg but assignscalaridbeforemov() sees BPFADDCONST on reg and assigns a new id to it.

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

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

0: (85) call bpfgetprandomu32#7 ; R0=scalar() 1: (57) r0 &= 255 ; R0=scalar(smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) 2: (bf) r1 = r0 ; R0=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) R1=scalar(id=1,smin=smin32=0,smax=umax=smax32=umax32=255,varoff=(0x0; 0xff)) 3: (07) r1 += 4 ; R1=scalar(id=1+4,smin=umin=smin32=umin32=4,smax=umax=smax32=umax32=259,varoff=(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,varoff=(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,varoff=(0x0; 0x1ff)) 7: (35) if r0 >= 0xa goto pc+1 ; R0=scalar(id=2,smin=umin=smin32=umin32=6,smax=umax=smax32=umax32=9,varoff=(0x0; 0xf)) 8: (37) r0 /= 0 div by zero

When 4 is verified, r1's bounds are propagated to r0 but r0 also gets BPFADDCONST (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 synclinkedregs() like off and subreg_def.