CVE-2024-41003: bpf: Fix reg_set_min_max corruption of fake_reg

Published Jul 12, 2024
·
Updated

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

6 affected componentsFixes available
debian/linux
5.10.223-15.10.234-16.1.129-16.1.135-16.12.25-16.12.27-1
Linux Linux kernel>=6.8<6.9.7
Linux Linux kernel=6.10-rc1
Linux Linux kernel=6.10-rc2
Linux Linux kernel=6.10-rc3
Linux Linux kernel=6.10-rc4

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade debian/linux to 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

Jul 12, 2024
CVE Published
via MITRE·12:44 PM
Data Sourced
via MITRE·12:44 PM
DescriptionSeverity
Data Sourced
via NVD·01:15 PM
Description
Data Sourced
via NVD·01:15 PM
RemedySeverityWeaknessAffected Software
Nov 30, 2024
Data Sourced
via Ubuntu·04:47 PM
RemedyDescriptionSeverityAffected Software

Frequently Asked Questions

1

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.

2

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.

3

What systems are affected by CVE-2024-41003?

CVE-2024-41003 affects specific versions of the Linux kernel used in Debian-based systems.

4

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.

5

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203