Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: platform/x86: x86-android-tablets: Se corrige el use after free en errores platform_device_register() x86_android_tablet_remove() libera la matriz pdevs[], por lo que no se debe utilizar después de llamar a x86_android_tablet_remove(). cuando falla platform_device_register(), almacena el valor PTR_ERR() de pdevs[x] en la variable ret local antes de llamar a x86_android_tablet_remove() para evitar usar pdevs[] después de que se haya liberado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: amdkfd_free_gtt_mem borra el puntero correcto. Pase la referencia del puntero a amdgpu_bo_unref para borrar el puntero correcto; de lo contrario, amdgpu_bo_unref borra la variable local, el puntero original no está establecido en NULL, esto podría causar un error de use after free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/stm: Evite problemas de use after free con crtc y plane ltdc_load() llama a las funciones drm_crtc_init_with_planes(), drm_universal_plane_init() y drm_encoder_init(). Estas funciones no deben llamarse con parámetros asignados con devm_kzalloc() para evitar problemas de use after free [1]. Use asignaciones administradas por el framework DRM. Encontrado por Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: lantiq_etop: fix memory breach Al aplicar relleno, el búfer no se pone a cero, lo que da como resultado la divulgación de memoria. Los datos mencionados se observan en el cable. Este parche usa skb_put_padto() para rellenar los marcos Ethernet correctamente. La función mencionada pone a cero el búfer expandido. En caso de que el paquete no se pueda rellenar, se descarta silenciosamente. Las estadísticas tampoco se incrementan. Este controlador no admite estadísticas en el antiguo formato de 32 bits ni en el nuevo formato de 64 bits. Estos se agregarán en el futuro. En su forma actual, el parche debería poder retroportarse fácilmente a versiones estables. Las MAC de Ethernet en Amazon-SE y Danube no pueden realizar relleno de los paquetes en hardware, por lo que se debe aplicar relleno de software.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: mejorar la secuencia de apagado Alexander Sverdlin presenta 2 problemas durante el apagado con el controlador lan9303. Uno es específico de lan9303 y el otro simplemente se reproduce allí. El primer problema es que lan9303 es único entre los controladores DSA en el sentido de que llama a dev_get_drvdata() en un "tiempo de ejecución arbitrario" (no sondeo, no apagado, no eliminación): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() Pero nunca detenemos phy_state_machine(), por lo que puede continuar ejecutándose después de dsa_switch_shutdown(). Nuestro patrón común en todos los controladores DSA es establecer drvdata en NULL para suprimir el método remove() que puede venir después. Pero en este caso resultará en un NPD. El segundo problema es que la forma en que establecemos dp->conduit->dsa_ptr = NULL; es concurrente con el procesamiento de paquetes de recepción. dsa_switch_rcv() verifica una vez si dev->dsa_ptr es NULL, pero después, en lugar de continuar usando ese valor no NULL, dev->dsa_ptr se desreferencia una y otra vez sin verificaciones NULL: dsa_conduit_find_user() y muchos otros lugares. Entre desreferencias, no hay bloqueo para asegurar que lo que era válido una vez continúa siendo válido. Ambos problemas tienen el aspecto común de que cerrar la interfaz del conducto los resuelve. En el primer caso, dev_close(conduit) activa el evento NETDEV_GOING_DOWN en dsa_user_netdevice_event() que también cierra los puertos de usuario. dsa_port_disable_rt() llama a phylink_stop(), que detiene sincrónicamente la máquina de estado de phylink, y ds->ops->phy_read() ya no llamará al controlador después de este punto. En el segundo caso, dev_close(conduit) debería hacer esto, según Documentation/networking/driver.rst: | Quiescence | ---------- | | Después de que se haya llamado a la rutina ndo_stop, el hardware no debe recibir ni transmitir ningún dato. Todos los paquetes en tránsito deben ser abortados. Si es necesario, sondee o espere a que se completen los comandos de reinicio. Por lo tanto, debería ser suficiente para garantizar que más adelante, cuando pongamos a cero conduit->dsa_ptr, no habrá ninguna llamada dsa_switch_rcv() concurrente en este conducto. La adición de la función netif_device_detach() es para garantizar que las solicitudes ioctls, rtnetlinks y ethtool en los puertos de usuario ya no se propaguen al controlador; ya no estamos preparados para manejarlas. La condición de ejecución en realidad no existía cuando el commit 0650bf52b31f ("net: dsa: sea compatible con los maestros que cancelan el registro al apagar") introdujo por primera vez dsa_switch_shutdown(). Se creó más tarde, cuando dejamos de cancelar el registro de las interfaces de usuario desde un lugar incorrecto y simplemente reemplazamos esa secuencia con una puesta a cero de ejecución de conduit->dsa_ptr (que no garantiza que las interfaces no estén activas).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Aumentar el tamaño de la matriz de dummy_boolean [POR QUÉ] dml2_core_shared_mode_support y dml_core_mode_support acceden al tercer elemento de dummy_boolean, es decir, hw_debug5 = &s->dummy_boolean[2], cuando dummy_boolean tiene un tamaño de 2. Cualquier asignación a hw_debug5 provoca un OVERRUN. [CÓMO] Aumentar el tamaño de la matriz de dummy_boolean a 3. Esto corrige 2 problemas de OVERRUN informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Desasignar memoria DML si falla la asignación [Por qué] Cuando falla la asignación de memoria DML al crear un estado de DC, la memoria no se desasigna posteriormente, lo que da como resultado una estructura no inicializada que no es NULL. [Cómo] Desasignar memoria si falla la asignación de memoria DML.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing/timerlat: eliminar interface_lock en stop_kthread() stop_kthread() es la devolución de llamada fuera de línea para "trace/osnoise:online", desde el commit 5bfbcd1ee57b ("tracing/timerlat: agregar interface_lock alrededor de la limpieza de kthread en stop_kthread()"), se introduce el siguiente escenario de bloqueo ABBA: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | Como interface_lock aquí solo sirve para proteger el campo "kthread" de osn_var, utilice xchg() en su lugar para solucionar este problema. Utilice también for_each_online_cpu() en stop_per_cpu_kthreads(), ya que puede volver a activar cpu_read_lock().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: gso: arregla la segmentación de tcp fraglist después de extraer de frag_list Detecta skbs tcp gso fraglist con geometría corrupta (ver abajo) y pásalos a skb_segment en lugar de a skb_segment_list, ya que el primero puede segmentarlos correctamente. Skbs SKB_GSO_FRAGLIST válidos: consisten en dos o más segmentos: el head_skb contiene los encabezados de protocolo más el primer gso_size: uno o más skbs frag_list contienen exactamente un segmento: todos menos el último deben ser gso_size Los ganchos de ruta de datos opcionales como NAT y BPF (bpf_skb_pull_data) pueden modificar estos skbs, rompiendo estos invariantes. En casos extremos, extraen todos los datos en skb lineal. Para TCP, esto provoca un desreferenciado de ptr NULL en __tcpv4_gso_segment_list_csum en tcp_hdr(seg->next). Detecta geometría no válida debido a la extracción, verificando el tamaño de head_skb. No lo descartes, ya que esto puede convertir un destino en un agujero negro. Convierte para poder pasar a skb_segment normal. Enfoque y descripción basados en un parche de Willem de Bruijn.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vrf: revert "vrf: Remove unexpected RCU-bh critical section" Esto revierte el commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. Se espera que dev_queue_xmit_nit se llame con BH deshabilitado. __dev_queue_xmit tiene lo siguiente: /* Deshabilitar irqs suaves para varios bloqueos a continuación. También * detiene la preempción para RCU. */ rcu_read_lock_bh(); VRF debe seguir esta invariante. el commit a la que se hace referencia eliminó esta protección. Lo que activó una advertencia de lockdep: ================================= ADVERTENCIA: estado de bloqueo inconsistente 6.11.0 #1 Tainted: GW -------------------------------- uso inconsistente de {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W}. btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] toma: ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, en: tpacket_rcv+0x863/0x3b30 {IN-SOFTIRQ-W} el estado se registró en: lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 packet_rcv+0xa33/0x1320 __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 __netif_receive_skb_list_core+0x2c9/0x890 netif_receive_skb_list_internal+0x610/0xcc0 [...] otra información que podría ayudar Depuremos esto: Posible escenario de bloqueo inseguro: CPU0 ---- lock(rlock-AF_PACKET); lock(rlock-AF_PACKET); *** BLOQUEO INTERMEDIO *** Seguimiento de llamadas: dump_stack_lvl+0x73/0xa0 mark_lock+0x102e/0x16b0 __lock_acquire+0x9ae/0x6170 lock_acquire+0x19a/0x4f0 _raw_spin_lock+0x27/0x40 tpacket_rcv+0x863/0x3b30 dev_queue_xmit_nit+0x709/0xa40 vrf_finish_direct+0x26e/0x340 [vrf] vrf_l3_out+0x5f4/0xe80 [vrf] __ip_local_out+0x51e/0x7a0 [...]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/v3d: Evitar el acceso fuera de los límites en las extensiones de consulta de rendimiento. Compruebe que la cantidad de espacio de usuario de perfmons que pasa en las extensiones de copia y restablecimiento no sea mayor que el almacenamiento interno del kernel donde se copiarán los identificadores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: r8169: se agregaron campos del contador de recuento con RTL8125. RTL8125 agregó campos al contador de recuento, lo que puede provocar que el chip desactive estos nuevos campos en la memoria no asignada. Por lo tanto, asegúrese de que el área de memoria asignada sea lo suficientemente grande como para contener todos los valores del contador de recuento, incluso si solo usamos partes de ella.