UBUNTU-CVE-2024-53680
In the Linux kernel, the following vulnerability has been resolved: ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init() Under certain kernel configurations when building with Clang/LLVM, the compiler does not generate a return or jump as the terminator instruction for ip_vs_protocol_init(), triggering the following objtool warning during build time: vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6() At runtime, this either causes an oops when trying to load the ipvs module or a boot-time panic if ipvs is built-in. This same issue has been reported by the Intel kernel test robot previously. Digging deeper into both LLVM and the kernel code reveals this to be a undefined behavior problem. ip_vs_protocol_init() uses a on-stack buffer of 64 chars to store the registered protocol names and leaves it uninitialized after definition. The function calls strnlen() when concatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCE strnlen() performs an extra step to check whether the last byte of the input char buffer is a null character (commit 3009f891bb9f ("fortify: Allow strlen() and strnlen() to pass compile-time known lengths")). This, together with possibly other configurations, cause the following IR to be generated: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 { %1 = alloca [64 x i8], align 16 ... 14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23 20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ... 23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... } The above code calculates the address of the last char in the buffer (value %15) and then loads from it (value %16). Because the buffer is never initialized, the LLVM GVN pass marks value %16 as undefined: %13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17 This gives later passes (SCCP, in particular) more DCE opportunities by propagating the undef value further, and eventually removes everything after the load on the uninitialized stack location: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 { %1 = alloca [64 x i8], align 16 ... 12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable } In this way, the generated native code will just fall through to the next function, as LLVM does not generate any code for the unreachable IR instruction and leaves the function without a terminator. Zero the on-stack buffer to avoid this possible UB.
02 / AFFECTED SOFTWARE
Affected packages
50 explicit affected versions
6 explicit affected versions
12 explicit affected versions
19 explicit affected versions
6 explicit affected versions
69 explicit affected versions
21 explicit affected versions
54 explicit affected versions
72 explicit affected versions
62 explicit affected versions
55 explicit affected versions
10 explicit affected versions
12 explicit affected versions
19 explicit affected versions
61 explicit affected versions
191 explicit affected versions
7 explicit affected versions
60 explicit affected versions
16 explicit affected versions
100 explicit affected versions
13 explicit affected versions
85 explicit affected versions
18 explicit affected versions
35 explicit affected versions
21 explicit affected versions
19 explicit affected versions
18 explicit affected versions
20 explicit affected versions
118 explicit affected versions
64 explicit affected versions
21 explicit affected versions
102 explicit affected versions
13 explicit affected versions
4 explicit affected versions
121 explicit affected versions
23 explicit affected versions
26 explicit affected versions
1 explicit affected versions
1 explicit affected versions
21 explicit affected versions
16 explicit affected versions
10 explicit affected versions
57 explicit affected versions
22 explicit affected versions
2 explicit affected versions
7 explicit affected versions
12 explicit affected versions
111 explicit affected versions
1 explicit affected versions
52 explicit affected versions
12 explicit affected versions
14 explicit affected versions
7 explicit affected versions
2 explicit affected versions
89 explicit affected versions
12 explicit affected versions
105 explicit affected versions
113 explicit affected versions
12 explicit affected versions
16 explicit affected versions
100 explicit affected versions
120 explicit affected versions
15 explicit affected versions
13 explicit affected versions
8 explicit affected versions
10 explicit affected versions
37 explicit affected versions
1 explicit affected versions
13 explicit affected versions
14 explicit affected versions
10 explicit affected versions
1 explicit affected versions
37 explicit affected versions
26 explicit affected versions
13 explicit affected versions
144 explicit affected versions
12 explicit affected versions
1 explicit affected versions
29 explicit affected versions
93 explicit affected versions
13 explicit affected versions
66 explicit affected versions
15 explicit affected versions
16 explicit affected versions
1 explicit affected versions
87 explicit affected versions
61 explicit affected versions
105 explicit affected versions
24 explicit affected versions
33 explicit affected versions
23 explicit affected versions
10 explicit affected versions
1 explicit affected versions
188 explicit affected versions
11 explicit affected versions
12 explicit affected versions
7 explicit affected versions
12 explicit affected versions
103 explicit affected versions
138 explicit affected versions
2 explicit affected versions
52 explicit affected versions
46 explicit affected versions
132 explicit affected versions
62 explicit affected versions
165 explicit affected versions
154 explicit affected versions
10 explicit affected versions
26 explicit affected versions
20 explicit affected versions
38 explicit affected versions
1 explicit affected versions
11 explicit affected versions
23 explicit affected versions
13 explicit affected versions
21 explicit affected versions
139 explicit affected versions
63 explicit affected versions
16 explicit affected versions
63 explicit affected versions
24 explicit affected versions
53 explicit affected versions
116 explicit affected versions
3 explicit affected versions
93 explicit affected versions
1 explicit affected versions
1 explicit affected versions
2 explicit affected versions
70 explicit affected versions
51 explicit affected versions
92 explicit affected versions
9 explicit affected versions
20 explicit affected versions
12 explicit affected versions
49 explicit affected versions
27 explicit affected versions
36 explicit affected versions
1 explicit affected versions
1 explicit affected versions
98 explicit affected versions
17 explicit affected versions
8 explicit affected versions
26 explicit affected versions
5 explicit affected versions
8 explicit affected versions
1 explicit affected versions
10 explicit affected versions
20 explicit affected versions
13 explicit affected versions
92 explicit affected versions
13 explicit affected versions
56 explicit affected versions
7 explicit affected versions
140 explicit affected versions
2 explicit affected versions
94 explicit affected versions
54 explicit affected versions
10 explicit affected versions
12 explicit affected versions
15 explicit affected versions
91 explicit affected versions
44 explicit affected versions
16 explicit affected versions
3 explicit affected versions
13 explicit affected versions
26 explicit affected versions
45 explicit affected versions
37 explicit affected versions
25 explicit affected versions
14 explicit affected versions
38 explicit affected versions
167 explicit affected versions
53 explicit affected versions
9 explicit affected versions
51 explicit affected versions
11 explicit affected versions
15 explicit affected versions
7 explicit affected versions
62 explicit affected versions
7 explicit affected versions
33 explicit affected versions
97 explicit affected versions
64 explicit affected versions
121 explicit affected versions
4 explicit affected versions
1 explicit affected versions
1 explicit affected versions
1 explicit affected versions
60 explicit affected versions
13 explicit affected versions
43 explicit affected versions
58 explicit affected versions
10 explicit affected versions
8 explicit affected versions
19 explicit affected versions
14 explicit affected versions
92 explicit affected versions
4 explicit affected versions
78 explicit affected versions
11 explicit affected versions
1 explicit affected versions
69 explicit affected versions
14 explicit affected versions
11 explicit affected versions
43 explicit affected versions
59 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
In the Linux kernel, the following vulnerability has been resolved: ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init() Under certain kernel configurations when building with Clang/LLVM, the compiler does not generate a return or jump as the terminator instruction for ip_vs_protocol_init(), triggering the following objtool warning during build time: vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6() At runtime, this either causes an oops when trying to load the ipvs module or a boot-time panic if ipvs is built-in. This same issue has been reported by the Intel kernel test robot previously. Digging deeper into both LLVM and the kernel code reveals this to be a undefined behavior problem. ip_vs_protocol_init() uses a on-stack buffer of 64 chars to store the registered protocol names and leaves it uninitialized after definition. The function calls strnlen() when concatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCE strnlen() performs an extra step to check whether the last byte of the input char buffer is a null character (commit 3009f891bb9f ("fortify: Allow strlen() and strnlen() to pass compile-time known lengths")). This, together with possibly other configurations, cause the following IR to be generated: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 { %1 = alloca [64 x i8], align 16 ... 14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23 20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ... 23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... } The above code calculates the address of the last char in the buffer (value %15) and then loads from it (value %16). Because the buffer is never initialized, the LLVM GVN pass marks value %16 as undefined: %13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17 This gives later passes (SCCP, in particular) more DCE opportunities by propagating the undef value further, and eventually removes everything after the load on the uninitialized stack location: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 { %1 = alloca [64 x i8], align 16 ... 12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable } In this way, the generated native code will just fall through to the next function, as LLVM does not generate any code for the unreachable IR instruction and leaves the function without a terminator. Zero the on-stack buffer to avoid this possible UB.
05 / REFERENCES
Further evidence
- https://ubuntu.com/security/CVE-2024-53680
- https://ubuntu.com/security/notices/USN-7379-1
- https://ubuntu.com/security/notices/USN-7379-2
- https://ubuntu.com/security/notices/USN-7380-1
- https://ubuntu.com/security/notices/USN-7381-1
- https://ubuntu.com/security/notices/USN-7382-1
- https://ubuntu.com/security/notices/USN-7387-1
- https://ubuntu.com/security/notices/USN-7387-2
- https://ubuntu.com/security/notices/USN-7387-3
- https://ubuntu.com/security/notices/USN-7388-1
- https://ubuntu.com/security/notices/USN-7389-1
- https://ubuntu.com/security/notices/USN-7390-1
- https://ubuntu.com/security/notices/USN-7391-1
- https://ubuntu.com/security/notices/USN-7392-1
- https://ubuntu.com/security/notices/USN-7392-2
- https://ubuntu.com/security/notices/USN-7392-3
- https://ubuntu.com/security/notices/USN-7392-4
- https://ubuntu.com/security/notices/USN-7393-1
- https://ubuntu.com/security/notices/USN-7401-1
- https://ubuntu.com/security/notices/USN-7407-1
- https://ubuntu.com/security/notices/USN-7413-1
- https://ubuntu.com/security/notices/USN-7421-1
- https://ubuntu.com/security/notices/USN-7449-1
- https://ubuntu.com/security/notices/USN-7449-2
- https://ubuntu.com/security/notices/USN-7450-1
- https://ubuntu.com/security/notices/USN-7451-1
- https://ubuntu.com/security/notices/USN-7452-1
- https://ubuntu.com/security/notices/USN-7453-1
- https://ubuntu.com/security/notices/USN-7458-1
- https://ubuntu.com/security/notices/USN-7459-1
- https://ubuntu.com/security/notices/USN-7459-2
- https://ubuntu.com/security/notices/USN-7463-1
- https://ubuntu.com/security/notices/USN-7468-1
- https://ubuntu.com/security/notices/USN-7523-1
- https://ubuntu.com/security/notices/USN-7524-1
- https://ubuntu.com/security/notices/USN-7539-1
- https://ubuntu.com/security/notices/USN-7540-1
- https://www.cve.org/CVERecord?id=CVE-2024-53680