Vulnerabilidades

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.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: ops: Verificar límites para el segundo canal en snd_soc_put_volsw_sx() Las comprobaciones de los límites en snd_soc_put_volsw_sx() solo se aplican al primer canal, lo que significa que es posible escribir valores fuera de los límites en el segundo canal en controles estéreo. Agregue las comprobaciones adecuadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: mt7621: Agregar centinela a la tabla de peculiaridades Al controlador actual le falta un centinela en la matriz struct soc_device_attribute, lo que provoca un error cuando se evalúa mediante la llamada soc_device_match(mt7621_pcie_quirks_match). Esto solo se expuso una vez que se arregló CONFIG_SOC_MT7621 mt7621 soc_dev_attr para registrar el SOC como un dispositivo, en: commit 7c18b64bba3b ("mips: ralink: mt7621: no use kzalloc demasiado pronto") Arréglelo agregando el centinela requerido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtc: cmos: Fix event handler registration ordering issue Debido a que acpi_install_fixed_event_handler() habilita el evento automáticamente en caso de éxito, es incorrecto llamarlo antes de que la rutina del controlador que se le pasa esté lista para manejar eventos. Desafortunadamente, el controlador rtc-cmos hace exactamente lo incorrecto al llamar a cmos_wake_setup(), que pasa rtc_handler() a acpi_install_fixed_event_handler(), antes de cmos_do_probe(), porque rtc_handler() usa dev_get_drvdata() para llegar al puntero del objeto cmos y el puntero de datos del controlador solo se completa en cmos_do_probe(). Esto conduce a una desreferencia de puntero NULL en rtc_handler() en el arranque si el evento RTC fixed está activo en el momento de inicialización. Para solucionar este problema, cambie el orden de inicialización del controlador de modo que cmos_wake_setup() siempre se llame después de una llamada a cmos_do_probe() exitosa. Mientras tanto, cambie cmos_pnp_probe() para llamar a cmos_do_probe() después de la declaración if () inicial utilizada para calcular el argumento IRQ que se pasará a cmos_do_probe(), lo que es más limpio que llamarlo en cada rama de ese if () (la variable local "irq" puede ser de tipo int, porque se pasa a esa función como un argumento de tipo int). Tenga en cuenta que el commit 6492fed7d8c9 ("rtc: rtc-cmos: No marque ACPI_FADT_LOW_POWER_S0") provocó que este problema afectara a una mayor cantidad de sistemas, porque anteriormente solo afectaba a los sistemas con ACPI_FADT_LOW_POWER_S0 configurado, pero está presente independientemente de esa confirmación.