CVE-2024-53680

一、漏洞信息
 漏洞编号：[CVE-2024-53680](https://nvd.nist.gov/vuln/detail/CVE-2024-53680)
 漏洞归属组件：[kernel](https://gitee.com/src-openeuler/kernel)
 漏洞归属的版本：4.19.140,4.19.194,4.19.90,5.10.0,6.1.19,6.1.8,6.4.0,6.6.0
 CVSS V3.0分值：
  BaseScore：5.5 Medium
  Vector：CVSS：3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
 漏洞简述：
  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, thecompiler does not generate a return or jump as the terminatorinstruction for ip_vs_protocol_init(), triggering the following objtoolwarning 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 ipvsmodule or a boot-time panic if ipvs is built-in. This same issue hasbeen reported by the Intel kernel test robot previously.Digging deeper into both LLVM and the kernel code reveals this to be aundefined behavior problem. ip_vs_protocol_init() uses a on-stack bufferof 64 chars to store the registered protocol names and leaves ituninitialized after definition. The function calls strnlen() whenconcatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCEstrnlen() performs an extra step to check whether the last byte of theinput 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 followingIR 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 isnever initialized, the LLVM GVN pass marks value %16 as undefined:  %13 = getelementptr inbounds i8, ptr %1, i64 63  br i1 undef, label %14, label %17This gives later passes (SCCP, in particular) more DCE opportunities bypropagating the undef value further, and eventually removes everythingafter 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 thenext function, as LLVM does not generate any code for the unreachable IRinstruction and leaves the function without a terminator.Zero the on-stack buffer to avoid this possible UB.
 漏洞公开时间：2025-01-11 21:15:25
 漏洞创建时间：2025-01-16 21:31:07
 漏洞详情参考链接：
  https://nvd.nist.gov/vuln/detail/CVE-2024-53680
<details>
<summary>更多参考(点击展开)</summary>

| 参考来源 | 参考链接 | 来源链接 |
| ------- | -------- | -------- |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/0b2cbed82b7c6504a8a0fbd181f92dd56b432c12 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/124834133b32f9386bb2d8581d9ab92f65e951e4 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/146b6f1112eb30a19776d6c323c994e9d67790db |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/31d1ddc1ce8e8d3f101a679243abb42a313ee88a |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/48130002e64fd191b7d18efeb4d253fcc23e4688 |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/664d0feab92495b6a27edc3d1119e232c0fe8b2b |  |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/d6e1776f51c95827142f1d7064118e255e2deec1 |  |
| suse_bugzilla | http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-53680 | https://bugzilla.suse.com/show_bug.cgi?id=1235715 |
| suse_bugzilla | https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-53680.mbox | https://bugzilla.suse.com/show_bug.cgi?id=1235715 |
| suse_bugzilla | https://git.kernel.org/stable/c/31d1ddc1ce8e8d3f101a679243abb42a313ee88a | https://bugzilla.suse.com/show_bug.cgi?id=1235715 |
| suse_bugzilla | https://git.kernel.org/stable/c/0b2cbed82b7c6504a8a0fbd181f92dd56b432c12 | https://bugzilla.suse.com/show_bug.cgi?id=1235715 |
| suse_bugzilla | https://git.kernel.org/stable/c/d6e1776f51c95827142f1d7064118e255e2deec1 | https://bugzilla.suse.com/show_bug.cgi?id=1235715 |
| suse_bugzilla | https://git.kernel.org/stable/c/664d0feab92495b6a27edc3d1119e232c0fe8b2b | https://bugzilla.suse.com/show_bug.cgi?id=1235715 |
| suse_bugzilla | https://git.kernel.org/stable/c/124834133b32f9386bb2d8581d9ab92f65e951e4 | https://bugzilla.suse.com/show_bug.cgi?id=1235715 |
| suse_bugzilla | https://git.kernel.org/stable/c/48130002e64fd191b7d18efeb4d253fcc23e4688 | https://bugzilla.suse.com/show_bug.cgi?id=1235715 |
| suse_bugzilla | https://git.kernel.org/stable/c/146b6f1112eb30a19776d6c323c994e9d67790db | https://bugzilla.suse.com/show_bug.cgi?id=1235715 |
| suse_bugzilla | https://www.cve.org/CVERecord?id=CVE-2024-53680 | https://bugzilla.suse.com/show_bug.cgi?id=1235715 |
| suse_bugzilla | https://bugzilla.redhat.com/show_bug.cgi?id=2337124 | https://bugzilla.suse.com/show_bug.cgi?id=1235715 |
| debian |  | https://security-tracker.debian.org/tracker/CVE-2024-53680 |
| mageia |  | http://advisories.mageia.org/MGASA-2025-0030.html |

</details>

漏洞分析指导链接：
  https://gitee.com/openeuler/cve-manager/blob/master/cve-vulner-manager/doc/md/manual.md
 漏洞数据来源:
  其它
 漏洞补丁信息：
  <details>
<summary>详情(点击展开)</summary>

| 影响的包 | 修复版本 | 修复补丁 | 问题引入补丁 | 来源  |
| ------- | -------- | ------- | -------- | --------- |
| linux_kernel | 5.4.287 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=31d1ddc1ce8e8d3f101a679243abb42a313ee88aIssue | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | linuxkernelcves |
| linux_kernel | 5.10.231 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0b2cbed82b7c6504a8a0fbd181f92dd56b432c12Issue | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | linuxkernelcves |
| linux_kernel | 5.15.174 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d6e1776f51c95827142f1d7064118e255e2deec1Issue | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | linuxkernelcves |
| linux_kernel | 6.1.120 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=664d0feab92495b6a27edc3d1119e232c0fe8b2bIssue | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | linuxkernelcves |
| linux_kernel | 6.6.66 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=124834133b32f9386bb2d8581d9ab92f65e951e4Issue | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | linuxkernelcves |
| linux_kernel | 6.12.5 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=48130002e64fd191b7d18efeb4d253fcc23e4688Issue | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | linuxkernelcves |
| linux_kernel | 6.13-rc2 | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=146b6f1112eb30a19776d6c323c994e9d67790dbPlease | https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 | linuxkernelcves |

</details>

二、漏洞分析结构反馈
 影响性分析说明：
  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, thecompiler does not generate a return or jump as the terminatorinstruction for ip_vs_protocol_init(), triggering the following objtoolwarning 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 ipvsmodule or a boot-time panic if ipvs is built-in. This same issue hasbeen reported by the Intel kernel test robot previously.Digging deeper into both LLVM and the kernel code reveals this to be aundefined behavior problem. ip_vs_protocol_init() uses a on-stack bufferof 64 chars to store the registered protocol names and leaves ituninitialized after definition. The function calls strnlen() whenconcatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCEstrnlen() performs an extra step to check whether the last byte of theinput 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 followingIR 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 isnever initialized, the LLVM GVN pass marks value %16 as undefined:  %13 = getelementptr inbounds i8, ptr %1, i64 63  br i1 undef, label %14, label %17This gives later passes (SCCP, in particular) more DCE opportunities bypropagating the undef value further, and eventually removes everythingafter 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 thenext function, as LLVM does not generate any code for the unreachable IRinstruction and leaves the function without a terminator.Zero the on-stack buffer to avoid this possible UB.
 openEuler评分：
  5.8
 Vector：CVSS：3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
 受影响版本排查(受影响/不受影响)：
  1.openEuler-20.03-LTS-SP4(4.19.90):受影响
2.openEuler-22.03-LTS-SP3(5.10.0):受影响
3.openEuler-22.03-LTS-SP4(5.10.0):受影响
4.openEuler-24.03-LTS(6.6.0):受影响
5.openEuler-24.03-LTS-SP1(6.6.0):受影响
6.openEuler-24.03-LTS-SP2(6.6.0):受影响
7.master(6.6.0):不受影响
8.openEuler-24.03-LTS-Next(6.6.0):不受影响

修复是否涉及abi变化(是/否)：
  1.openEuler-20.03-LTS-SP4(4.19.90):否
2.openEuler-22.03-LTS-SP3(5.10.0):否
3.master(6.6.0):否
4.openEuler-24.03-LTS(6.6.0):否
5.openEuler-24.03-LTS-Next(6.6.0):否
6.openEuler-22.03-LTS-SP4(5.10.0):否
7.openEuler-24.03-LTS-SP1(6.6.0):否
8.openEuler-24.03-LTS-SP2(6.6.0):否

原因说明：
  1.openEuler-24.03-LTS(6.6.0):正常修复
2.openEuler-24.03-LTS-SP1(6.6.0):正常修复
3.openEuler-24.03-LTS-SP2(6.6.0):正常修复
4.openEuler-20.03-LTS-SP4(4.19.90):不修复-超出修复范围
5.openEuler-22.03-LTS-SP3(5.10.0):不修复-超出修复范围
6.openEuler-22.03-LTS-SP4(5.10.0):不修复-超出修复范围
7.master(6.6.0):不受影响-漏洞代码不能被攻击者触发
8.openEuler-24.03-LTS-Next(6.6.0):不受影响-漏洞代码不能被攻击者触发

src-openEuler/kernel

Content Risk Flag

Comments (24)

src-openEuler/kernel .gitee-modal { width: 500px !important; }

Content Risk Flag

CVE-2024-53680

Comments (24)

Search

src-openEuler/kernel