Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Se corrige la descarga de puertos virtuales de ECVF durante el flujo de apagado. Se corrige el UAF del flujo de apagado cuando se crea una función virtual en el chip integrado (ECVF) de un dispositivo BlueField. En tal caso, la tabla de entrada ACL del puerto virtual no se destruye correctamente. La funcionalidad de ECVF es independiente de la capacidad ecpf_vport_exists y, por lo tanto, las funciones mlx5_eswitch_(enable|disable)_pf_vf_vports() no deberían probarla al habilitar o deshabilitar los puertos virtuales de ECVF. Registro del kernel: [] refcount_t: desbordamiento; use-after-free. [] ADVERTENCIA: CPU: 3 PID: 1 at lib/refcount.c:28 refcount_warn_saturate+0x124/0x220 ---------------- [] Call trace: [] refcount_warn_saturate+0x124/0x220 [] tree_put_node+0x164/0x1e0 [mlx5_core] [] mlx5_destroy_flow_table+0x98/0x2c0 [mlx5_core] [] esw_acl_ingress_table_destroy+0x28/0x40 [mlx5_core] [] esw_acl_ingress_lgcy_cleanup+0x80/0xf4 [mlx5_core] [] esw_legacy_vport_acl_cleanup+0x44/0x60 [mlx5_core] [] esw_vport_cleanup+0x64/0x90 [mlx5_core] [] mlx5_esw_vport_disable+0xc0/0x1d0 [mlx5_core] [] mlx5_eswitch_unload_ec_vf_vports+0xcc/0x150 [mlx5_core] [] mlx5_eswitch_disable_sriov+0x198/0x2a0 [mlx5_core] [] mlx5_device_disable_sriov+0xb8/0x1e0 [mlx5_core] [] mlx5_sriov_detach+0x40/0x50 [mlx5_core] [] mlx5_unload+0x40/0xc4 [mlx5_core] [] mlx5_unload_one_devl_locked+0x6c/0xe4 [mlx5_core] [] mlx5_unload_one+0x3c/0x60 [mlx5_core] [] shutdown+0x7c/0xa4 [mlx5_core] [] pci_device_shutdown+0x3c/0xa0 [] device_shutdown+0x170/0x340 [] __do_sys_reboot+0x1f4/0x2a0 [] __arm64_sys_reboot+0x2c/0x40 [] invoke_syscall+0x78/0x100 [] el0_svc_common.constprop.0+0x54/0x184 [] do_el0_svc+0x30/0xac [] el0_svc+0x48/0x160 [] el0t_64_sync_handler+0xa4/0x12c [] el0t_64_sync+0x1a4/0x1a8 [] --[ fin de seguimiento 9c4601d68c70030e ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mdiobus: Arregla el potencial acceso de lectura/escritura fuera de los límites de la cláusula 45 Cuando se usan herramientas disponibles públicamente como 'mdio-tools' para leer/escribir datos desde/hacia la interfaz de red y su PHY a través de C45 (cláusula 45) mdiobus, no hay verificación de los parámetros pasados a ioctl y acepta cualquier dirección mdio. Actualmente hay soporte para 32 direcciones en el kernel a través de la definición PHY_MAX_ADDR, pero es posible pasar un valor más alto que ese a través de ioctl. Si bien la operación de lectura/escritura generalmente debería fallar en este caso, mdiobus proporciona una matriz de estadísticas, donde la dirección incorrecta puede permitir lectura/escritura fuera de los límites. Arregla eso agregando la verificación de dirección antes de la operación de lectura/escritura C45. Si bien esto excluye este acceso de cualquier estadística, mejora la seguridad de la operación de lectura/escritura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mdiobus: corrige el posible acceso de lectura/escritura fuera de los límites Cuando se utilizan herramientas disponibles públicamente como 'mdio-tools' para leer/escribir datos desde/hacia la interfaz de red y su PHY a través de mdiobus, no hay verificación de los parámetros pasados a ioctl y acepta cualquier dirección mdio. Actualmente hay soporte para 32 direcciones en el kernel a través de la definición PHY_MAX_ADDR, pero es posible pasar un valor más alto que ese a través de ioctl. Si bien la operación de lectura/escritura generalmente debería fallar en este caso, mdiobus proporciona una matriz de estadísticas, donde la dirección incorrecta puede permitir la lectura/escritura fuera de los límites. Corrija eso agregando la verificación de dirección antes de la operación de lectura/escritura. Si bien esto excluye este acceso de cualquier estadística, mejora la seguridad de la operación de lectura/escritura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: Se solucionó el problema de TOCTOU en sk_is_readable(). sk->sk_prot->sock_is_readable es un puntero a función válido cuando sk reside en un mapa de sockets. Tras el último sk_psock_put() (que suele ocurrir al eliminar un socket de un mapa de sockets), sk->sk_prot se restaura y sk->sk_prot->sock_is_readable se convierte en NULL. Esto hace que sk_is_readable() sea arriesgado si el valor de sk->sk_prot se recarga después de la comprobación inicial. Esto, a su vez, puede provocar una desreferencia de puntero nulo. Asegúrese de que el puntero a función no se convierta en NULL después de la comprobación.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: espintcp: eliminar el almacenamiento en caché del socket encap para evitar fugas de referencia El esquema actual para almacenar en caché el socket encap puede provocar fugas de referencia cuando intentamos eliminar los netns. La cadena de referencia es: xfrm_state -> enacp_sk -> netns Dado que el socket encap es un socket de espacio de usuario, contiene una referencia en los netns. Si eliminamos el estado de espintcp (a través de vaciado o eliminación individual) antes de eliminar los netns, la referencia en el socket se elimina y los netns se eliminan correctamente. De lo contrario, los netns pueden no ser accesibles más (si todos los procesos dentro de los ns han terminado), por lo que no podemos eliminar el estado xfrm para eliminar su referencia en el socket. Este parche da como resultado una pequeña regresión del rendimiento (~2% en mis pruebas). Se podría agregar un mecanismo de tipo GC para el caché del socket, para borrar referencias si el estado no se ha usado "recientemente", pero es mucho más complejo que simplemente no almacenar en caché el socket.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: No trate el conector wb como físico en create_validate_stream_for_sink. No intente operar en un drm_wb_connector como un amdgpu_dm_connector. Aunque desreferenciar aconnector->base funciona, es incorrecto y podría provocar problemas desconocidos. Simplemente... no lo haga.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: deshabilitar la compatibilidad con SCO si READ_VOICE_SETTING no es compatible o está roto. Una conexión SCO sin el voice_setting adecuado puede provocar que el controlador se bloquee.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/iopl: Solucionar inconsistencias de TIF_IO_BITMAP. io_bitmap_exit() se invoca desde exit_thread() cuando existe una tarea o cuando falla una bifurcación. En este último caso, exit_thread() limpia los recursos asignados durante fork(). io_bitmap_exit() invoca task_update_io_bitmap(), que a su vez termina en tss_update_io_bitmap(). tss_update_io_bitmap() opera en la tarea actual. Si la tarea actual tiene TIF_IO_BITMAP configurado, pero no hay ningún mapa de bits instalado, tss_update_io_bitmap() se bloquea con una desreferencia de puntero NULL. Hay dos problemas que conducen a este problema: 1) io_bitmap_exit() no debería invocar task_update_io_bitmap() cuando la tarea, que se limpia, no es la tarea actual. Esto es un indicador claro de una limpieza después de un fork() fallido. 2) Una tarea no debe tener TIF_IO_BITMAP establecido ni un mapa de bits instalado ni el nivel de emulación IOPL 3 activado. Esto sucede cuando se crea un hilo del kernel en el contexto de un hilo del espacio de usuario, que tiene TIF_IO_BITMAP establecido a medida que se copian los indicadores del hilo y se borra el puntero del mapa de bits de E/S. Aparte del caso del fork() fallido, esto no tiene impacto porque los hilos del kernel, incluidos los trabajadores de E/S, nunca vuelven al espacio de usuario y, por lo tanto, nunca invocan tss_update_io_bitmap(). Solucione esto añadiendo las limpiezas y comprobaciones que faltan: 1) Evite que io_bitmap_exit() invoque task_update_io_bitmap() si la tarea que se va a limpiar no es la tarea actual. 2) Borre TIF_IO_BITMAP en copy_thread() incondicionalmente. Para las bifurcaciones del espacio de usuario, se establece más tarde, cuando el mapa de bits de E/S se hereda en io_bitmap_share(). Por el bien de la paranoia, agregue una advertencia en tss_update_io_bitmap() para detectar el caso en el que ese código se invoca con un estado inconsistente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ring-buffer: Se corrige el bloqueo del búfer en ring_buffer_subbuf_order_set() Se amplía la sección crítica en ring_buffer_subbuf_order_set() para garantizar que el manejo de errores se realice con el mutex por búfer retenido, evitando así la corrupción de listas y otros problemas relacionados con la concurrencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: VMCI: corregir la ejecución entre vmci_host_setup_notify y vmci_ctx_unset_notify Durante nuestra prueba, se encontró que se puede activar una advertencia en try_grab_folio de la siguiente manera: ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 0 PID: 1678 en mm/gup.c:147 try_grab_folio+0x106/0x130 Módulos vinculados: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 No contaminado 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Rastreo de llamadas: follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ fin del seguimiento 000000000000000 ]--- Al analizar el código fuente, es posible que context->notify_page se inicialice mediante get_user_pages_fast, lo que se puede observar en vmci_ctx_unset_notify, que intentará ejecutar put_page. Sin embargo, get_user_pages_fast no ha finalizado y genera la siguiente advertencia try_grab_folio. La condición de ejecución se muestra de la siguiente manera: cpu0 cpu1 vmci_host_do_set_notify vmci_host_setup_notify get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page); lockless_pages_from_mm gup_pgd_range gup_huge_pmd // actualizar &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // la página está liberada __gup_longterm_locked __get_user_pages follow_trans_huge_pmd try_grab_folio // advertir aquí Para solucionar esto, use la variable local page para hacer que notify_page se pueda ver después de finalizar get_user_pages_fast.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: usbhid: Elimina el error recurrente fuera de los límites en usbhid_parse() Actualiza la estructura hid_descriptor para reflejar mejor las partes obligatorias y opcionales del descriptor HID según la especificación USB HID 1.11. Nota: el kernel actualmente no analiza ningún descriptor de clase HID opcional, solo el descriptor de informe obligatorio. Actualiza todas las referencias al elemento miembro desc[0] a rpt_desc. Agrega una prueba para verificar que los valores de bLength y bNumDescriptors sean válidos. Reemplaza el bucle for con acceso directo al miembro descriptor de clase HID obligatorio para el descriptor de informe. Esto elimina la posibilidad de obtener un fallo fuera de los límites. Agrega un mensaje de advertencia si el descriptor HID contiene algún descriptor de clase HID opcional no compatible.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb-audio: Kill timer properly at removal El código MIDI USB-audio inicializa el temporizador, pero en un caso raro, el controlador podría liberarse sin la llamada de desconexión. Esto deja al temporizador en un estado activo mientras el objeto asignado se libera a través de snd_usbmidi_free(), lo que termina con una advertencia del kernel cuando se habilita la configuración de depuración, como lo detectó un fuzzer. Para evitar el problema, coloque timer_shutdown_sync() en snd_usbmidi_free(), para que el temporizador pueda ser eliminado correctamente. Mientras estamos en ello, reemplace también el timer_delete_sync() existente en la devolución de llamada de desconexión con timer_shutdown_sync().