Vulnerabilidades

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net: ethernet: mtk_eth_soc: Restablecer puntero de programa a old_prog en caso de error en mtk_xdp_setup()<br /> <br /> Restablecer puntero de programa eBPF a old_prog y no disminuir su contador de referencias si la rutina mtk_open en mtk_xdp_setup() falla.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> drbd: corrección de desreferencia de puntero nulo en error de lectura local<br /> <br /> En drbd_request_endio(), READ_COMPLETED_WITH_ERROR se pasa a __req_mod() con un peer_device NULO:<br /> <br /> __req_mod(req, what, NULL, &amp;amp;m);<br /> <br /> El gestor de READ_COMPLETED_WITH_ERROR luego pasa incondicionalmente este peer_device NULO a drbd_set_out_of_sync(), que lo desreferencia, causando una desreferencia de puntero nulo.<br /> <br /> Esto se corrige obteniendo el peer_device a través de first_peer_device(device), coincidiendo con cómo drbd_req_destroy() maneja la misma situación.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> atm: lec: corrige desreferencia de puntero nulo en lec_arp_clear_vccs<br /> <br /> syzkaller reportó una desreferencia de puntero nulo en lec_arp_clear_vccs().<br /> Este problema puede ser fácilmente reproducido usando el reproductor de syzkaller.<br /> <br /> En el módulo ATM LANE (Emulación de LAN), el mismo atm_vcc puede ser compartido por múltiples entradas de lec_arp_table (por ejemplo, a través de entry-&amp;gt;vcc o entry-&amp;gt;recv_vcc).<br /> Cuando el VCC subyacente se cierra, lec_vcc_close() itera sobre todas las entradas ARP y llama a lec_arp_clear_vccs() para cada entrada coincidente.<br /> <br /> Por ejemplo, cuando lec_vcc_close() itera a través de las hlists en priv-&amp;gt;lec_arp_empty_ones u otras tablas ARP:<br /> <br /> 1. En la primera iteración, para la primera entrada ARP coincidente que comparte el VCC, lec_arp_clear_vccs() libera el vpriv asociado (que es vcc-&amp;gt;user_back) y establece vcc-&amp;gt;user_back en NULL.<br /> 2. En la segunda iteración, para la siguiente entrada ARP coincidente que comparte el mismo VCC, lec_arp_clear_vccs() es llamada de nuevo. Obtiene un vpriv NULL de vcc-&amp;gt;user_back (a través de LEC_VCC_PRIV(vcc)) y luego intenta desreferenciarlo a través de &amp;#39;vcc-&amp;gt;pop = vpriv-&amp;gt;old_pop&amp;#39;, lo que lleva a un fallo por desreferencia de puntero nulo.<br /> <br /> Soluciona esto añadiendo una comprobación de nulos para vpriv antes de desreferenciarlo. Si vpriv ya es NULL, significa que el VCC ha sido limpiado por una llamada anterior, por lo que podemos omitir de forma segura la limpieza y simplemente limpiar los punteros vcc/recv_vcc de la entrada.<br /> <br /> El bloque de limpieza completo (incluyendo vcc_release_async()) se coloca dentro de la guarda de vpriv porque un vpriv NULL indica que el VCC ya ha sido completamente liberado por una iteración anterior — repetir el desmontaje establecería banderas de forma redundante y activaría retrollamadas en un socket que ya se está cerrando.<br /> <br /> La etiqueta Fixes apunta al commit inicial porque la ruta entry-&amp;gt;vcc ha sido vulnerable desde el código original. La ruta entry-&amp;gt;recv_vcc fue añadida posteriormente por el commit 8d9f73c0ad2f (&amp;#39;atm: fix a memory leak of vcc-&amp;gt;user_back&amp;#39;) con el mismo patrón, y ambas rutas se corrigen aquí.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> irqchip/sifive-plic: Solución para la interrupción congelada debido a la configuración de afinidad<br /> <br /> PLIC ignora el mensaje de finalización de interrupción para interrupciones deshabilitadas, explicado por la especificación:<br /> <br /> El PLIC señala que ha completado la ejecución de un gestor de interrupciones escribiendo el ID de interrupción que recibió de la solicitud en el registro de solicitud/finalización. El PLIC no verifica si el ID de finalización es el mismo que el último ID de solicitud para ese objetivo. Si el ID de finalización no coincide con una fuente de interrupción que está actualmente habilitada para el objetivo, la finalización es ignorada silenciosamente.<br /> <br /> Esto causó problemas en el pasado, porque una interrupción puede ser deshabilitada mientras aún está siendo gestionada y plic_irq_eoi() no tenía efecto. Eso se solucionó verificando si la interrupción está deshabilitada, y si es así, habilitarla, antes de enviar el mensaje de finalización. Esa verificación se realiza con irqd_irq_disabled().<br /> <br /> Sin embargo, eso no es suficiente porque el bit de habilitación para el hart de gestión puede ser cero a pesar de que irqd_irq_disabled(d) sea falso. Esto puede ocurrir cuando la configuración de afinidad se cambia mientras un hart todavía está gestionando la interrupción.<br /> <br /> Este problema es fácilmente reproducible volcando un archivo grande a la uart (lo que genera muchas interrupciones) y al mismo tiempo seguir cambiando la configuración de afinidad de la interrupción de la uart. El puerto de la uart se congela casi instantáneamente.<br /> <br /> Solucione esto verificando el bit de habilitación del PLIC en lugar de irqd_irq_disabled().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> IB/mthca: Añadir mthca_unmap_user_db() que se había omitido para mthca_create_srq()<br /> <br /> Corregir una fuga activable por el usuario en la ruta de fallo de la llamada al sistema.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> accel/amdxdna: Prevenir desbordamiento del tamaño de ubuf<br /> <br /> El cálculo del tamaño de ubuf puede desbordarse, resultando en una asignación de tamaño insuficiente y posible corrupción de memoria.<br /> <br /> Usar ayudantes check_add_overflow() para validar el cálculo del tamaño antes de la asignación.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: mac80211: corrige la desreferencia de puntero NULL en mesh_rx_csa_frame()<br /> <br /> En mesh_rx_csa_frame(), elems-&amp;gt;mesh_chansw_params_ie es desreferenciado en las líneas 1638 y 1642 sin una verificación de NULL previa:<br /> <br /> ifmsh-&amp;gt;chsw_ttl = elems-&amp;gt;mesh_chansw_params_ie-&amp;gt;mesh_ttl;<br /> ...<br /> pre_value = le16_to_cpu(elems-&amp;gt;mesh_chansw_params_ie-&amp;gt;mesh_pre_value);<br /> <br /> La verificación mesh_matches_local() anterior solo valida el ID de Malla, la Configuración de Malla y los IEs de Tasas Soportadas. No verifica la presencia del IE de Parámetros de Cambio de Canal de Malla (ID de elemento 118). Cuando un frame de acción CSA recibido omite ese IE, ieee802_11_parse_elems() deja elems-&amp;gt;mesh_chansw_params_ie como NULL, y la desreferencia incondicional causa una desreferencia de puntero NULL del kernel.<br /> <br /> Un par de malla remoto con un enlace de par establecido (PLINK_ESTAB) puede activar esto enviando un frame de acción SPECTRUM_MGMT/CHL_SWITCH manipulado que incluye un ID de Malla y un IE de Configuración de Malla coincidentes, pero omite el IE de Parámetros de Cambio de Canal de Malla. No se requiere autenticación más allá del emparejamiento de malla abierta predeterminado.<br /> <br /> Fallo confirmado en el kernel 6.17.0-5-generic a través de mac80211_hwsim:<br /> <br /> BUG: desreferencia de puntero NULL del kernel, dirección: 0000000000000000<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> RIP: 0010:ieee80211_mesh_rx_queued_mgmt+0x143/0x2a0 [mac80211]<br /> CR2: 0000000000000000<br /> <br /> Solución añadiendo una verificación de NULL para mesh_chansw_params_ie después de que mesh_matches_local() retorne, consistente con cómo otros IEs opcionales son protegidos a lo largo del código de malla.<br /> <br /> El error ha estado presente desde la v3.13 (lanzada el 19-01-2014).

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> wifi: libertas: corregir uso después de liberación en lbs_free_adapter()<br /> <br /> La función lbs_free_adapter() usa timer_delete() (no síncrono) para command_timer y tx_lockup_timer antes de que la estructura sea liberada. Esto es incorrecto porque timer_delete() no espera a que ninguna devolución de llamada de temporizador en ejecución se complete.<br /> <br /> Si una devolución de llamada de temporizador se está ejecutando cuando se llama a lbs_free_adapter(), la devolución de llamada accederá a memoria liberada ya que lbs_cfg_free() libera la estructura contenedora inmediatamente después de que lbs_free_adapter() retorna.<br /> <br /> Ambas devoluciones de llamada de temporizador (lbs_cmd_timeout_handler y lbs_tx_lockup_handler) acceden a priv-&amp;gt;driver_lock, priv-&amp;gt;cur_cmd, priv-&amp;gt;dev y otros campos, lo que serían todas violaciones de uso después de liberación.<br /> <br /> Usar timer_delete_sync() en su lugar para asegurar que cualquier devolución de llamada de temporizador en ejecución se haya completado antes de retornar.<br /> <br /> Este error fue introducido en el commit 8f641d93c38a (&amp;#39;libertas: detectar bloqueos de TX y reiniciar hardware&amp;#39;) donde se usó del_timer() en lugar de del_timer_sync() en la ruta de limpieza. El command_timer ha tenido el mismo problema desde que el controlador fue escrito por primera vez.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> smb: cliente: corregir oops debido a una variable no inicializada en smb2_unlink()<br /> <br /> Si SMB2_open_init() o SMB2_close_init() falla (por ejemplo, reconexión), el conjunto de iovs @rqst quedará sin inicializar, por lo tanto, llamar a SMB2_open_free(), SMB2_close_free() o smb2_set_related() en ellos causará un oops.<br /> <br /> Solucionar esto inicializando @close_iov y @open_iov antes de establecerlos en @rqst.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> regulador: fp9931: Corrección de fuga de referencia de tiempo de ejecución de PM en fp9931_hwmon_read()<br /> <br /> En fp9931_hwmon_read(), si regmap_read() fallaba, la función devolvía el código de error sin llamar a pm_runtime_put_autosuspend(), causando una fuga de referencia de PM.

Enviar un mensaje diseñado maliciosamente a los demonios kea-ctrl-agent, kea-dhcp-ddns, kea-dhcp4 o kea-dhcp6 a través de cualquier socket API o oyente HA configurado puede provocar que el demonio receptor se cierre con un error de desbordamiento de pila.<br /> Este problema afecta a las versiones de Kea 2.6.0 a 2.6.4 y 3.0.0 a 3.0.2.

Los routers SHARP no realizan autenticación para algunas API web. La información del dispositivo puede ser recuperada sin autenticación. Si la contraseña administrativa del dispositivo se deja como la inicial, el dispositivo puede ser tomado.