Detections
Analytics

Google: sys-kernel/csql-kernel-6_1, sys-kernel/lakitu-kernel-6_1: security update to 18244.291.3

medium Tenable Cloud Security Plugin ID 451819

Description

There are packages installed that are affected by a vulnerability referenced in the following CVE:

 - 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. (CVE-2024-53680)

Solution

Update the sys-kernel/csql-kernel-6_1 library and its related packages to version 18244.291.3 or later.

See Also

https://storage.googleapis.com/cos-oval-vulnerability-feed/cos-113.oval.xml.tar.gz

Plugin Details

Severity: Medium

ID: 451819

Version: Revision 1.1

Type: Local

Published: 10/1/2026

Updated: 10/1/2026

Risk Information

VPR

Risk Factor: Medium

Score: 5

Percentile: 95.06

Vendor

Vendor Severity: MEDIUM

CVSS v2

Risk Factor: Medium

Base Score: 4.6

Temporal Score: 3.4

Vector: CVSS2#AV:L/AC:L/Au:S/C:N/I:N/A:C

CVSS Score Source: CVE-2024-53680

CVSS v3

Risk Factor: Medium

Base Score: 5.5

Temporal Score: 4.8

Vector: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

Exploit Ease: No known exploits are available

Vulnerability Publication Date: 1/8/2025

Reference Information

CVE: CVE-2024-53680