CVE-2024-41003: bpf: Fix reg_set_min_max corruption of fake_reg
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: R6w=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 ; R6w=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---
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 5.10.223-1Fixed in 5.10.234-1Fixed in 6.1.129-1Fixed in 6.1.135-1Fixed in 6.12.25-1Fixed in 6.12.27-1
Event History
Frequently Asked Questions
What is the severity of CVE-2024-41003?
CVE-2024-41003 has a medium severity rating due to its impact on the Linux kernel's BPF functionality.
How do I fix CVE-2024-41003?
To fix CVE-2024-41003, update the Linux kernel to one of the patched versions: 5.10.223-1, 5.10.226-1, 6.1.119-1, 6.1.123-1, 6.12.11-1, or 6.12.12-1.
What systems are affected by CVE-2024-41003?
CVE-2024-41003 affects specific versions of the Linux kernel used in Debian-based systems.
What is the impact of CVE-2024-41003?
The impact of CVE-2024-41003 may include potential corruption of register values in BPF, which could lead to unexpected behavior in kernel operations.
Who reported CVE-2024-41003?
CVE-2024-41003 was reported by a user named Juan, who observed issues while testing a new fuzzing strategy for the kernel.