CVE-2024-41003

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

bpf: Fix regsetminmax corruption of fakereg

Juan reported that after doing some changes to buzzer [0] and implementing a new fuzzing strategy guided by coverage, they noticed the following in one of the probes:

[...] 13: (79) r6 = *(u64 *)(r0 +0) ; R0=mapvalue(ks=4,vs=8) R6w=scalar() 14: (b7) r0 = 0 ; R0w=0 15: (b4) w0 = -1 ; R0w=0xffffffff 16: (74) w0 >>= 1 ; R0w=0x7fffffff 17: (5c) w6 &= w0 ; R0w=0x7fffffff R6w=scalar(smin=smin32=0,smax=umax=umax32=0x7fffffff,varoff=(0x0; 0x7fffffff)) 18: (44) w6 |= 2 ; R6w=scalar(smin=umin=smin32=umin32=2,smax=umax=umax32=0x7fffffff,varoff=(0x2; 0x7ffffffd)) 19: (56) if w6 != 0x7ffffffd goto pc+1 REG INVARIANTS VIOLATION (truereg2): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] varoff=(0x7fffffff, 0x0) REG INVARIANTS VIOLATION (falsereg1): range bounds violation u64=[0x7fffffff, 0x7ffffffd] s64=[0x7fffffff, 0x7ffffffd] u32=[0x7fffffff, 0x7ffffffd] s32=[0x7fffffff, 0x7ffffffd] varoff=(0x7fffffff, 0x0) REG INVARIANTS VIOLATION (falsereg2): const tnum out of sync with range bounds u64=[0x0, 0xffffffffffffffff] s64=[0x8000000000000000, 0x7fffffffffffffff] u32=[0x0, 0xffffffff] s32=[0x80000000, 0x7fffffff] varoff=(0x7fffffff, 0x0) 19: R6_w=0x7fffffff 20: (95) exit

from 19 to 21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,varoff=(0x2; 0x7ffffffd)) R7=mapptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=mapptr(ks=4,vs=8) fp-40=mmmmmmmm 21: R0=0x7fffffff R6=scalar(smin=umin=smin32=umin32=2,smax=umax=smax32=umax32=0x7ffffffe,varoff=(0x2; 0x7ffffffd)) R7=mapptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=mapptr(ks=4,vs=8) fp-40=mmmmmmmm 21: (14) w6 -= 2147483632 ; R6w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=14,varoff=(0x2; 0xfffffffd)) 22: (76) if w6 s>= 0xe goto pc+1 ; R6w=scalar(smin=umin=umin32=2,smax=umax=0xffffffff,smin32=0x80000012,smax32=13,varoff=(0x2; 0xfffffffd)) 23: (95) exit

from 22 to 24: R0=0x7fffffff R6w=14 R7=mapptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=mapptr(ks=4,vs=8) fp-40=mmmmmmmm 24: R0=0x7fffffff R6w=14 R7=mapptr(ks=4,vs=8) R9=ctx() R10=fp0 fp-24=mapptr(ks=4,vs=8) fp-40=mmmmmmmm 24: (14) w6 -= 14 ; R6_w=0 [...]

What can be seen here is a register invariant violation on line 19. After the binary-or in line 18, the verifier knows that bit 2 is set but knows nothing about the rest of the content which was loaded from a map value, meaning, range is [2,0x7fffffff] with varoff=(0x2; 0x7ffffffd). When in line 19 the verifier analyzes the branch, it splits the register states in regsetminmax() into the registers of the true branch (truereg1, truereg2) and the registers of the false branch (falsereg1, falsereg2).

Since the test is w6 != 0x7ffffffd, the srcreg is a known constant. Internally, the verifier creates a "fake" register initialized as scalar to the value of 0x7ffffffd, and then passes it onto regsetminmax(). Now, for line 19, it is mathematically impossible to take the false branch of this program, yet the verifier analyzes it. It is impossible because the second bit of r6 will be set due to the prior or operation and the constant in the condition has that bit unset (hex(fd) == binary(1111 1101).

When the verifier first analyzes the false / fall-through branch, it will compute an intersection between the varoff of r6 and of the constant. This is because the verifier creates a "fake" register initialized to the value of the constant. The intersection result later refines both registers in regsrefinecondop():

[...] t = tnumintersect(tnumsubreg(reg1->varoff), tnumsubreg(reg2->varoff)); reg1->varo ---truncated---