nvd-json-data-feeds/CVE-2024/CVE-2024-536xx/CVE-2024-53680.json

{
  "id": "CVE-2024-53680",
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "published": "2025-01-11T13:15:25.710",
  "lastModified": "2025-01-11T13:15:25.710",
  "vulnStatus": "Awaiting Analysis",
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipvs: correcci\u00f3n de UB debido a acceso a pila no inicializado en ip_vs_protocol_init() En determinadas configuraciones del kernel al compilar con Clang/LLVM, el compilador no genera un retorno o salto como instrucci\u00f3n de terminaci\u00f3n para ip_vs_protocol_init(), lo que activa la siguiente advertencia de objtool durante el tiempo de compilaci\u00f3n: vmlinux.o: advertencia: objtool: ip_vs_protocol_init() pasa a la siguiente funci\u00f3n __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6() En tiempo de ejecuci\u00f3n, esto provoca un error al intentar cargar el m\u00f3dulo ipvs o un p\u00e1nico en el tiempo de arranque si ipvs est\u00e1 integrado. El robot de prueba del kernel de Intel ha informado anteriormente de este mismo problema. Al investigar m\u00e1s a fondo tanto en LLVM como en el c\u00f3digo del kernel, se revela que se trata de un problema de comportamiento indefinido. ip_vs_protocol_init() utiliza un b\u00fafer en pila de 64 caracteres para almacenar los nombres de protocolo registrados y lo deja sin inicializar despu\u00e9s de la definici\u00f3n. La funci\u00f3n llama a strnlen() al concatenar nombres de protocolo en el b\u00fafer. Con CONFIG_FORTIFY_SOURCE, strnlen() realiza un paso adicional para verificar si el \u00faltimo byte del b\u00fafer de caracteres de entrada es un car\u00e1cter nulo (commit 3009f891bb9f (\"fortify: Permitir que strlen() y strnlen() pasen longitudes conocidas en tiempo de compilaci\u00f3n\")). Esto, junto con posiblemente otras configuraciones, hace que se genere la siguiente IR: 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 = cargar i8, ptr %15, alinear 1 %17 = cola llamar i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = seleccionar i1 %17, i1 %18, i1 falso br i1 %19, etiqueta %20, etiqueta %23 20: ; preds = %14 %21 = llamar 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 ... } El c\u00f3digo anterior calcula la direcci\u00f3n del \u00faltimo car\u00e1cter en el b\u00fafer (valor %15) y luego carga desde \u00e9l (valor %16). Como el buffer nunca se inicializa, el paso GVN de LLVM marca el valor %16 como indefinido: %13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17 Esto otorga a los pases posteriores (SCCP, en particular) m\u00e1s oportunidades de DCE al propagar m\u00e1s el valor indefinido y, eventualmente, elimina todo despu\u00e9s de la carga en la ubicaci\u00f3n de la pila no inicializada: 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 } De esta manera, el c\u00f3digo nativo generado simplemente pasar\u00e1 a la siguiente funci\u00f3n, ya que LLVM no genera ning\u00fan c\u00f3digo para la instrucci\u00f3n IR inalcanzable y deja la funci\u00f3n sin un terminador. Ponga a cero el b\u00fafer en la pila para evitar este posible UB."
    }
  ],
  "metrics": {},
  "references": [
    {
      "url": "https://git.kernel.org/stable/c/0b2cbed82b7c6504a8a0fbd181f92dd56b432c12",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/124834133b32f9386bb2d8581d9ab92f65e951e4",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/146b6f1112eb30a19776d6c323c994e9d67790db",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/31d1ddc1ce8e8d3f101a679243abb42a313ee88a",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/48130002e64fd191b7d18efeb4d253fcc23e4688",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/664d0feab92495b6a27edc3d1119e232c0fe8b2b",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    },
    {
      "url": "https://git.kernel.org/stable/c/d6e1776f51c95827142f1d7064118e255e2deec1",
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ]
}