{"cve":"CVE-2024-53680","nvd":{"published":"2025-01-11T13:15:25.710","modified":"2026-06-17T08:09:05.410","status":"Modified","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()\n\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:\n\n  vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()\n\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.\n\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:\n\n  define 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    ...\n\n  14:                                               ; 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\n    br i1 %19, label %20, label %23\n\n  20:                                               ; preds = %14\n    %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23\n    ...\n\n  23:                                               ; preds = %14, %11, %20\n    %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24\n    ...\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\n  %13 = getelementptr inbounds i8, ptr %1, i64 63\n  br i1 undef, label %14, label %17\n\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:\n\n  define 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    ...\n\n  12:                                               ; preds = %11\n    %13 = getelementptr inbounds i8, ptr %1, i64 63\n    unreachable\n  }\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.\n\nZero the on-stack buffer to avoid this possible UB.","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","score":5.5},"cwes":["CWE-908"],"references":["https://git.kernel.org/stable/c/0b2cbed82b7c6504a8a0fbd181f92dd56b432c12","https://git.kernel.org/stable/c/124834133b32f9386bb2d8581d9ab92f65e951e4","https://git.kernel.org/stable/c/146b6f1112eb30a19776d6c323c994e9d67790db","https://git.kernel.org/stable/c/31d1ddc1ce8e8d3f101a679243abb42a313ee88a","https://git.kernel.org/stable/c/48130002e64fd191b7d18efeb4d253fcc23e4688"],"products":["linux:linux_kernel"],"source":"nvd","synced_at":"2026-10-19T21:58:20.756570362+00:00"},"epss":{"cve":"CVE-2024-53680","score":0.00229,"percentile":0.13765,"date":"2026-10-31"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}