Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igb: Se corrige un posible acceso no válido a la memoria en igb_init_module(). pci_register_driver() puede fallar y cuando esto sucede, se debe anular el registro de dca_notifier; de lo contrario, se puede llamar a dca_notifier cuando igb no se instala, lo que genera un acceso no válido a la memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipvs: corrección 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ón de terminación para ip_vs_protocol_init(), lo que activa la siguiente advertencia de objtool durante el tiempo de compilación: vmlinux.o: advertencia: objtool: ip_vs_protocol_init() pasa a la siguiente función __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6() En tiempo de ejecución, esto provoca un error al intentar cargar el módulo ipvs o un pánico en el tiempo de arranque si ipvs está integrado. El robot de prueba del kernel de Intel ha informado anteriormente de este mismo problema. Al investigar más a fondo tanto en LLVM como en el código del kernel, se revela que se trata de un problema de comportamiento indefinido. ip_vs_protocol_init() utiliza un búfer en pila de 64 caracteres para almacenar los nombres de protocolo registrados y lo deja sin inicializar después de la definición. La función llama a strnlen() al concatenar nombres de protocolo en el búfer. Con CONFIG_FORTIFY_SOURCE, strnlen() realiza un paso adicional para verificar si el último byte del búfer de caracteres de entrada es un carácter nulo (commit 3009f891bb9f ("fortify: Permitir que strlen() y strnlen() pasen longitudes conocidas en tiempo de compilación")). 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ódigo anterior calcula la dirección del último carácter en el búfer (valor %15) y luego carga desde él (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ás oportunidades de DCE al propagar más el valor indefinido y, eventualmente, elimina todo después de la carga en la ubicación 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ódigo nativo generado simplemente pasará a la siguiente función, ya que LLVM no genera ningún código para la instrucción IR inalcanzable y deja la función sin un terminador. Ponga a cero el búfer en la pila para evitar este posible UB.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: regulador: axp20x: AXP717: establecer ramp_delay La hoja de datos de AXP717 dice que el retraso de rampa del regulador es 15,625 us/paso, que es 10 mV en nuestro caso. Agregue una macro AXP_DESC_RANGES_DELAY y actualice la macro AXP_DESC_RANGES para expandir a AXP_DESC_RANGES_DELAY con ramp_delay = 0 Para DCDC4, los pasos son 100 mv Agregue una macro AXP_DESC_DELAY y actualice la macro AXP_DESC para expandir a AXP_DESC_DELAY con ramp_delay = 0 Este parche corrige fallas al usar CPU DVFS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: comprobar iparea_offset e ipv6_prefixes_cnt al recibir un mensaje de propuesta Al recibir un mensaje de propuesta en el servidor, el campo iparea_offset y el campo ipv6_prefixes_cnt en el mensaje de propuesta son del cliente remoto y no se puede confiar plenamente en ellos. Especialmente el campo iparea_offset, una vez que se excede el valor máximo, existe la posibilidad de acceder a una dirección incorrecta y puede producirse un bloqueo. Este parche comprueba iparea_offset e ipv6_prefixes_cnt antes de usarlos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sched/fair: Fix NEXT_BUDDY Adam informa que habilitar NEXT_BUDDY instantáneamente activa una ADVERTENCIA en pick_next_entity(). Mover clear_buddies() hacia arriba antes de los bits de eliminación de cola retrasados garantiza que ningún ->next buddy se retrase. Además, asegúrese de que ningún nuevo ->next buddy comience con retraso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: usar dirección alineada en copy_user_gigantic_page() En el kernel actual, hugetlb_wp() llama a copy_user_large_folio() con la dirección de error. Donde la dirección de error puede no estar alineada con el tamaño de página enorme. Entonces, copy_user_large_folio() puede llamar a copy_user_gigantic_page() con la dirección, mientras que copy_user_gigantic_page() requiere que la dirección esté alineada con el tamaño de página enorme. Por lo tanto, esto puede causar corrupción de memoria o fuga de información. Además, use un nombre más obvio 'addr_hint' en lugar de 'addr' para copy_user_gigantic_page().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: usar dirección alineada en clear_gigantic_page() En el kernel actual, hugetlb_no_page() llama a folio_zero_user() con la dirección de error. Donde la dirección de error puede no estar alineada con el tamaño de página enorme. Entonces, folio_zero_user() puede llamar a clear_gigantic_page() con la dirección, mientras que clear_gigantic_page() requiere que la dirección esté alineada con el tamaño de página enorme. Por lo tanto, esto puede causar corrupción de memoria o fuga de información. Además, use un nombre más obvio 'addr_hint' en lugar de 'addr' para clear_gigantic_page().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: mpc52xx: Agregar cancel_work_sync antes de eliminar el módulo Si eliminamos el módulo que llamará a mpc52xx_spi_remove, liberará 'ms' a través de spi_unregister_controller. mientras que se utilizará el trabajo ms->work. La secuencia de operaciones que puede provocar un error de UAF. Arréglelo asegurándose de que el trabajo se cancele antes de continuar con la desinfección en mpc52xx_spi_remove.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: stackdepot: se corrige stack_depot_save_flags() en el contexto NMI Según la documentación, se suponía que stack_depot_save_flags() se podía usar desde el contexto NMI si STACK_DEPOT_FLAG_CAN_ALLOC no está configurado. Sin embargo, aún intentaría tomar el pool_lock en un intento de guardar un seguimiento de pila en el pool actual (si hay espacio disponible). Esto podría resultar en un bloqueo si se gestiona un NMI mientras pool_lock ya está retenido. Para evitar el bloqueo, solo intente tomar el bloqueo en el contexto NMI y abandone si no tiene éxito. La documentación se corrige para transmitir esto claramente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bcache: revertir el reemplazo de IS_ERR_OR_NULL con IS_ERR nuevamente. El commit 028ddcac477b ("bcache: eliminar la comprobación innecesaria del punto NULL en las asignaciones de nodos") conduce a una deferencia de puntero NULL en cache_set_flush(). 1721 if (!IS_ERR_OR_NULL(c->root)) 1722 list_add(&c->root->list, &c->btree_cache); >Del código anterior en cache_set_flush(), si el código de registro anterior falla antes de asignar c->root, es posible que c->root sea NULL como lo que se inicializa. __bch_btree_node_alloc() nunca devuelve NULL, pero es posible que c->root sea NULL en la línea 1721 anterior. Este parche reemplaza IS_ERR() por IS_ERR_OR_NULL() para solucionar esto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/smc: comprobar v2_ext_offset/eid_cnt/ism_gid_cnt al recibir un mensaje de propuesta Al recibir un mensaje de propuesta en el servidor, los campos v2_ext_offset/eid_cnt/ism_gid_cnt en el mensaje de propuesta son del cliente remoto y no se puede confiar plenamente en ellos. Especialmente el campo v2_ext_offset, una vez que se excede el valor máximo, existe la posibilidad de acceder a una dirección incorrecta y puede producirse un bloqueo. Este parche comprueba los campos v2_ext_offset/eid_cnt/ism_gid_cnt antes de usarlos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-rdma: anular la desactivación de admin_q antes de destruirlo El kernel se bloqueará al destruir admin_q mientras creamos un control fallido, como el siguiente calltrace: PID: 23644 TAREA: ff2d52b40f439fc0 CPU: 2 COMANDO: "nvme" #0 [ff61d23de260fb78] __schedule en ffffffff8323bc15 #1 [ff61d23de260fc08] schedule en ffffffff8323c014 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait en ffffffff82a3dba1 #3 [ff61d23de260fc78] blk_freeze_queue en ffffffff82a4113a #4 [ff61d23de260fc90] blk_cleanup_queue en ffffffff82a33006 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue en ffffffffc12686ce #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl en ffffffffc1268ced #7 [ff61d23de260fd28] nvme_rdma_create_ctrl en ffffffffc126919b #8 [ff61d23de260fd68] nvmf_dev_write en ffffffffc024f362 #9 [ff61d23de260fe38] vfs_write en ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 00000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b Esto se debe a que hemos silenciado admi_q antes de cancelar solicitudes, pero olvidamos reactivarlo antes de destruirlo, como resultado no podemos drenar las solicitudes pendientes y nos quedamos colgados en blk_mq_freeze_queue_wait() para siempre. Aquí intente reutilizar nvme_rdma_teardown_admin_queue() para solucionar este problema y simplificar el código.