{"answers":{"affected":"It affects 1 product.","exploited":"There is no known exploitation of CVE-2024-53680 in the wild and no public exploit code.","fix":"Apply the vendor's patch.","what":"CVE-2024-53680 is a medium-severity vulnerability in Linux kernel, published on 11 Jan 2025. It can only be exploited from the same machine or local network, with no action from the victim."},"fix_prompt":"Check this codebase for CVE-2024-53680 and fix it if it is affected.\n\nWhat it is: CVE-2024-53680 is a medium-severity vulnerability in Linux kernel, published on 11 Jan 2025. It can only be exploited from the same machine or local network, with no action from the victim.\nExploitation: There is no known exploitation of CVE-2024-53680 in the wild and no public exploit code.\n\nAffected product: Linux kernel. No package-level version data is available, so check the vendor advisory linked from the reference page.\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2024-53680/ (Markdown: https://insights.sbomify.com/CVE-2024-53680/index.md)","id":"CVE-2024-53680","markdown":"https://insights.sbomify.com/CVE-2024-53680/index.md","name":"CVE-2024-53680","record":{"aliases":["BELL-CVE-2024-53680","DEBIAN-CVE-2024-53680","GHSA-5f32-qq4v-9hch","UBUNTU-CVE-2024-53680"],"analysis":{"component_type":"kernel","fix_type":"patch","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":true,"product_category":"Linux kernel IPVS","requires_auth":"low_privilege","summary":"Uninitialized stack access in Linux kernel IPVS module causes oops or boot panic, leading to denial of service.","user_interaction":"not_required","vuln_class":"null_dereference"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"Linux","cpe":[{"product":"linux_kernel","vendor":"linux"}],"cvss":{"score":5.5,"severity":"medium","source":"nvd","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","version":"3.1"},"cwes":[{"id":"CWE-908","name":"Use of Uninitialized Resource"}],"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.","ecosystems":[],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()","id":"CVE-2024-53680","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":null,"product":"linux:linux_kernel","products":["linux:linux_kernel"],"type":"null_dereference","year":"2024"},"n_packages":0,"n_references":7,"next":{"headline":"nvmet: Don't overflow subsysnqn","id":"CVE-2024-53681"},"packages":[],"prev":{"headline":"Apache VCL: XSS vulnerability in User Lookup impacting user privileges","id":"CVE-2024-53679"},"products":["Linux"],"published":"2025-01-11","related":[{"cvss_score":8.8,"headline":"Linux Kernel Out-of-Bounds Write","id":"CVE-2026-53266","kev_date_added":"2026-09-18","published":"2026-06-25"},{"cvss_score":8.8,"headline":"Linux Kernel Improper Input Validation","id":"CVE-2013-6282","kev_date_added":"2022-09-15","published":"2013-11-19"},{"cvss_score":8.4,"headline":"Linux Kernel Heap-Based Buffer Overflow","id":"CVE-2022-0185","kev_date_added":"2024-08-21","published":"2022-02-11"},{"cvss_score":8.4,"headline":"Linux Kernel Privilege Escalation","id":"CVE-2013-2094","kev_date_added":"2022-09-15","published":"2013-05-14"},{"cvss_score":7.8,"headline":"Linux Kernel Unspecified","id":"CVE-2026-53362","kev_date_added":"2026-08-27","published":"2026-07-04"},{"cvss_score":7.8,"headline":"Linux Kernel Missing Initialization of a Variable","id":"CVE-2026-46300","kev_date_added":"2026-10-28","published":"2026-05-23"},{"cvss_score":7.8,"headline":"Linux Kernel Race Condition","id":"CVE-2025-39964","kev_date_added":"2026-09-18","published":"2025-10-13"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":"PUBLISHED","updated":"2026-05-11","vendors":["Linux"]},"summary":"Uninitialized stack access in Linux kernel IPVS module causes oops or boot panic, leading to denial of service.","url":"https://insights.sbomify.com/CVE-2024-53680/"}