Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFC: nci: Comprobación de los límites de matrices struct nfc_target Mientras se ejecutaba bajo CONFIG_FORTIFY_SOURCE=y, syzkaller informó: memcpy: se detectó una escritura que abarcaba campos (tamaño 129) de un solo campo "target->sensf_res" en net/nfc/nci/ntf.c:260 (tamaño 18) Esto parece ser una falta legítima de comprobación de los límites en nci_add_new_protocol(). Agregue las comprobaciones faltantes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: octeontx2-pf: corrige una posible pérdida de memoria en otx2_init_tc(). En otx2_init_tc(), si rhashtable_init() fallo, no libera tc->tc_entries_bitmap que está asignado en otx2_tc_alloc_ent_bitmap().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: dpaa2-switch: corrige pérdida de memoria en dpaa2_switch_acl_entry_add() y dpaa2_switch_acl_entry_remove(). Es necesario liberar cmd_buff cuando ocurre un error en dpaa2_switch_acl_entry_add() y dpaa2_switch_acl_entry_remove().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ethernet: aeroflex: se corrige una posible fuga de skb en greth_init_rings() La función greth_init_rings() no liberará el skb recién asignado cuando dma_mapping_error() devuelva un error, por lo que se debe agregar dev_kfree_skb() para corregirlo. Solo se probó la compilación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: sja1105: se corrige una pérdida de memoria en sja1105_setup_devlink_regions() Cuando dsa_devlink_region_create fallo en sja1105_setup_devlink_regions(), priv->regions no se libera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: hisilicon: Se corrige un posible use after free en hix5hd2_rx() El skb se envía a napi_gro_receive() que puede liberarlo; después de llamarlo, desreferenciar skb puede desencadenar un use after free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: mdio: arregla el recuento de referencias de fwnode no balanceado en mdio_device_release() Hay un informe de advertencia sobre una fuga de recuento de referencias de of_node mientras se sondea el dispositivo mdio: OF: ERROR: fuga de memoria, se esperaba un recuento de referencias de 1 en lugar de 2, of_node_get()/of_node_put() no balanceado - destruye la entrada de cset: adjunta el nodo superpuesto /spi/soc@0/mdio@710700c0/ethernet@4 En of_mdiobus_register_device(), aumentamos el recuento de referencias de fwnode mediante fwnode_handle_get() antes de asociar el of_node con el dispositivo mdio, pero nunca se ha reducido en la ruta normal. Desde entonces, en mdio_device_release(), necesita llamar a fwnode_handle_put() además en lugar de llamar a kfree() directamente. Después de lo anterior, simplemente llamar a mdio_device_free() en la ruta del controlador de errores de of_mdiobus_register_device() es suficiente para mantener el recuento de referencias equilibrado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: udf: Se corrige el descarte de preasignación en el límite de extensión indirecta. Cuando la extensión de preasignación es la primera en el bloque de extensión, el código corrompería el encabezado del árbol de extensión. Corrija el problema y use udf_delete_aext() para eliminar la extensión y evitar la duplicación de código.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: L2CAP: Corregir desbordamiento de u8 Al seguir enviando paquetes L2CAP_CONF_REQ, chan->num_conf_rsp aumenta varias veces y eventualmente alcanzará el número máximo (es decir, 255). Este parche evita esto añadiendo una comprobación de los límites con L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Nota: Linux versión 6.1.0-rc2 (x86_64) 0.264594 = Nota: Subsistema Bluetooth versión 2.22 0.264636 @ MGMT Open: btmon (privilegiado) versión 1.22 {0x0001} 0.272191 = Nuevo índice: 00:00:00:00:00:00 (Principal,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privilegiado) versión 2.22 {0x0002} 13.890741 = Abierto Índice: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Manejar 200 indicadores 0x00 dlen 1033 #32 [hci0] 14.273106 tamaño de paquete no válido (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Manejar 200 indicadores 0x00 dlen 1547 #33 [hci0] 14.273561 tamaño de paquete no válido (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Manejar 200 indicadores 0x00 dlen 2061 #34 [hci0] 14.274390 tamaño de paquete no válido (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Manejar 200 indicadores 0x00 dlen 2061 #35 [hci0] 14.274932 tamaño de paquete no válido (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Daemon Bluetooth 5.43 14.401828 > ACL Data RX: Manejar 200 indicadores 0x00 dlen 1033 #36 [hci0] 14.275753 tamaño de paquete no válido (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@...

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: uvc: Evitar desbordamiento de búfer en el controlador de configuración La función de configuración uvc_function_setup permite solicitudes de transferencia de control con hasta 64 bytes de payload (UVC_MAX_REQUEST_SIZE), el controlador de etapa de datos para transferencia OUT usa memcpy para copiar req->actual bytes a la matriz uvc_event->data.data de tamaño 60. Esto puede resultar en un desbordamiento de 4 bytes.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: igb: inicializar mensaje de buzón para restablecer VF Cuando no se asigna una dirección MAC a la VF, esa parte del mensaje enviado a la VF no se configura. Sin embargo, la memoria se asigna desde la pila, lo que significa que la información puede filtrarse a la VM. Inicialice el búfer de mensajes a 0 para que no se pase información a la VM en este caso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: Fix perf_pending_task() UaF Por syzbot es posible que perf_pending_task() se ejecute después de que el evento sea free(). Hay dos casos relacionados pero distintos: - el task_work ya estaba en cola antes de destruir el evento; - destruir el evento en sí mismo pone en cola el task_work. El primero no se puede resolver usando task_work_cancel() ya que perf_release() en sí mismo podría ser llamado desde un task_work (____fput), lo que significa que la lista current->task_works ya está vacía y task_work_cancel() no podrá encontrar la entrada perf_pending_task(). La alternativa más simple es extender la duración de perf_event para cubrir el task_work. El segundo es simplemente una tontería, poner en cola una tarea_trabajo mientras sabes que el evento va a desaparecer no tiene sentido y se evita fácilmente reorganizando cómo se marca el evento como STATE_DEAD y asegurándose de que pase por STATE_OFF en el camino hacia abajo.