{
  "threat_severity" : "Moderate",
  "public_date" : "2025-01-11T00:00:00Z",
  "bugzilla" : {
    "description" : "kernel: ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()",
    "id" : "2337124",
    "url" : "https://bugzilla.redhat.com/show_bug.cgi?id=2337124"
  },
  "cvss3" : {
    "cvss3_base_score" : "5.5",
    "cvss3_scoring_vector" : "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
    "status" : "verified"
  },
  "cwe" : "CWE-457",
  "details" : [ "In the Linux kernel, the following vulnerability has been resolved:\nipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()\nUnder certain kernel configurations when building with Clang/LLVM, the\ncompiler does not generate a return or jump as the terminator\ninstruction for ip_vs_protocol_init(), triggering the following objtool\nwarning during build time:\nvmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()\nAt runtime, this either causes an oops when trying to load the ipvs\nmodule or a boot-time panic if ipvs is built-in. This same issue has\nbeen reported by the Intel kernel test robot previously.\nDigging deeper into both LLVM and the kernel code reveals this to be a\nundefined behavior problem. ip_vs_protocol_init() uses a on-stack buffer\nof 64 chars to store the registered protocol names and leaves it\nuninitialized after definition. The function calls strnlen() when\nconcatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCE\nstrnlen() performs an extra step to check whether the last byte of the\ninput char buffer is a null character (commit 3009f891bb9f (\"fortify:\nAllow strlen() and strnlen() to pass compile-time known lengths\")).\nThis, together with possibly other configurations, cause the following\nIR to be generated:\ndefine hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section \".init.text\" align 16 !kcfi_type !29 {\n%1 = alloca [64 x i8], align 16\n...\n14:                                               ; preds = %11\n%15 = getelementptr inbounds i8, ptr %1, i64 63\n%16 = load i8, ptr %15, align 1\n%17 = tail call i1 @llvm.is.constant.i8(i8 %16)\n%18 = icmp eq i8 %16, 0\n%19 = select i1 %17, i1 %18, i1 false\nbr i1 %19, label %20, label %23\n20:                                               ; preds = %14\n%21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23\n...\n23:                                               ; preds = %14, %11, %20\n%24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24\n...\n}\nThe above code calculates the address of the last char in the buffer\n(value %15) and then loads from it (value %16). Because the buffer is\nnever initialized, the LLVM GVN pass marks value %16 as undefined:\n%13 = getelementptr inbounds i8, ptr %1, i64 63\nbr i1 undef, label %14, label %17\nThis gives later passes (SCCP, in particular) more DCE opportunities by\npropagating the undef value further, and eventually removes everything\nafter the load on the uninitialized stack location:\ndefine hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section \".init.text\" align 16 !kcfi_type !11 {\n%1 = alloca [64 x i8], align 16\n...\n12:                                               ; preds = %11\n%13 = getelementptr inbounds i8, ptr %1, i64 63\nunreachable\n}\nIn this way, the generated native code will just fall through to the\nnext function, as LLVM does not generate any code for the unreachable IR\ninstruction and leaves the function without a terminator.\nZero the on-stack buffer to avoid this possible UB." ],
  "affected_release" : [ {
    "product_name" : "Red Hat Enterprise Linux 9",
    "release_date" : "2025-11-11T00:00:00Z",
    "advisory" : "RHSA-2025:20518",
    "cpe" : "cpe:/a:redhat:enterprise_linux:9",
    "package" : "kernel-0:5.14.0-611.5.1.el9_7"
  }, {
    "product_name" : "Red Hat Enterprise Linux 9",
    "release_date" : "2025-11-11T00:00:00Z",
    "advisory" : "RHSA-2025:20518",
    "cpe" : "cpe:/o:redhat:enterprise_linux:9",
    "package" : "kernel-0:5.14.0-611.5.1.el9_7"
  } ],
  "package_state" : [ {
    "product_name" : "Red Hat Enterprise Linux 6",
    "fix_state" : "Out of support scope",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:6"
  }, {
    "product_name" : "Red Hat Enterprise Linux 7",
    "fix_state" : "Out of support scope",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:7"
  }, {
    "product_name" : "Red Hat Enterprise Linux 7",
    "fix_state" : "Out of support scope",
    "package_name" : "kernel-rt",
    "cpe" : "cpe:/o:redhat:enterprise_linux:7"
  }, {
    "product_name" : "Red Hat Enterprise Linux 8",
    "fix_state" : "Out of support scope",
    "package_name" : "kernel",
    "cpe" : "cpe:/o:redhat:enterprise_linux:8"
  }, {
    "product_name" : "Red Hat Enterprise Linux 8",
    "fix_state" : "Out of support scope",
    "package_name" : "kernel-rt",
    "cpe" : "cpe:/o:redhat:enterprise_linux:8"
  }, {
    "product_name" : "Red Hat Enterprise Linux 9",
    "fix_state" : "Affected",
    "package_name" : "kernel-rt",
    "cpe" : "cpe:/o:redhat:enterprise_linux:9"
  } ],
  "references" : [ "https://www.cve.org/CVERecord?id=CVE-2024-53680\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-53680\nhttps://lore.kernel.org/linux-cve-announce/2025011123-CVE-2024-53680-88d4@gregkh/T" ],
  "name" : "CVE-2024-53680",
  "csaw" : false
}