Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: scsi: core: ufs: Se corrige un bloqueo en el gestor de errores cuando ufshcd_err_handling_prepare() invoca ufshcd_rpm_get_sync(). Esta última función solo funciona correctamente si UFSHCD_EH_IN_PROGRESS no está configurado, ya que la reanudación implica el envío de un comando SCSI y ufshcd_queuecommand() devuelve SCSI_MLQUEUE_HOST_BUSY si UFSHCD_EH_IN_PROGRESS está configurado. Para solucionar este bloqueo, configure UFSHCD_EH_IN_PROGRESS después de invocar ufshcd_rpm_get_sync() en lugar de antes. Rastreo inverso: __switch_to+0x174/0x338 __schedule+0x600/0x9e4 schedule+0x7c/0xe8 schedule_timeout+0xa4/0x1c8 io_schedule_timeout+0x48/0x70 wait_for_common_io+0xa8/0x160 //waiting on START_STOP wait_for_completion_io_timeout+0x10/0x20 blk_execute_rq+0xe4/0x1e4 scsi_execute_cmd+0x108/0x244 ufshcd_set_dev_pwr_mode+0xe8/0x250 __ufshcd_wl_resume+0x94/0x354 ufshcd_wl_runtime_resume+0x3c/0x174 scsi_runtime_resume+0x64/0xa4 rpm_resume+0x15c/0xa1c __pm_runtime_resume+0x4c/0x90 // Runtime resume ongoing ufshcd_err_handler+0x1a0/0xd08 process_one_work+0x174/0x808 worker_thread+0x15c/0x490 kthread+0xf4/0x1ec ret_from_fork+0x10/0x20 [ bvanassche: se reescribió la descripción del parche ]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corrección del use-after-free de sq->thread en __io_uring_show_fdinfo() syzbot informa: ERROR: KASAN: slab-use-after-free en getrusage+0x1109/0x1a60 Lectura de tamaño 8 en la dirección ffff88810de2d2c8 por la tarea a.out/304 CPU: 0 UID: 0 PID: 304 Comm: a.out No contaminado 6.16.0-rc1 #1 PREEMPT(voluntario) Nombre del hardware: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 Rastreo de llamadas: dump_stack_lvl+0x53/0x70 print_report+0xd0/0x670 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? getrusage+0x1109/0x1a60 kasan_report+0xce/0x100 ? getrusage+0x1109/0x1a60 getrusage+0x1109/0x1a60 ? __pfx_getrusage+0x10/0x10 __io_uring_show_fdinfo+0x9fe/0x1790 ? ksys_read+0xf7/0x1c0 ? do_syscall_64+0xa4/0x260 ? vsnprintf+0x591/0x1100 ? __pfx___io_uring_show_fdinfo+0x10/0x10 ? __pfx_vsnprintf+0x10/0x10 ? mutex_trylock+0xcf/0x130 ? __pfx_mutex_trylock+0x10/0x10 ? __pfx_show_fd_locks+0x10/0x10 ? io_uring_show_fdinfo+0x57/0x80 io_uring_show_fdinfo+0x57/0x80 seq_show+0x38c/0x690 seq_read_iter+0x3f7/0x1180 ? inode_set_ctime_current+0x160/0x4b0 seq_read+0x271/0x3e0 ? __pfx_seq_read+0x10/0x10 ? __pfx__raw_spin_lock+0x10/0x10 ? __mark_inode_dirty+0x402/0x810 ? selinux_file_permission+0x368/0x500 ? file_update_time+0x10f/0x160 vfs_read+0x177/0xa40 ? __pfx___handle_mm_fault+0x10/0x10 ? __pfx_vfs_read+0x10/0x10 ? mutex_lock+0x81/0xe0 ? __pfx_mutex_lock+0x10/0x10 ? fdget_pos+0x24d/0x4b0 ksys_read+0xf7/0x1c0 ? __pfx_ksys_read+0x10/0x10 ? do_user_addr_fault+0x43b/0x9c0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f0f74170fc9 Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 8 RSP: 002b:00007fffece049e8 EFLAGS: 00000206 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0f74170fc9 RDX: 0000000000001000 RSI: 00007fffece049f0 RDI: 0000000000000004 RBP: 00007fffece05ad0 R08: 0000000000000000 R09: 00007fffece04d90 R10: 0000000000000000 R11: 0000000000000206 R12: 00005651720a1100 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 298: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_node_noprof+0xe8/0x330 copy_process+0x376/0x5e00 create_io_thread+0xab/0xf0 io_sq_offload_create+0x9ed/0xf20 io_uring_setup+0x12b0/0x1cc0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 22: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0xc4/0x360 rcu_core+0x5ff/0x19f0 handle_softirqs+0x18c/0x530 run_ksoftirqd+0x20/0x30 smpboot_thread_fn+0x287/0x6c0 kthread+0x30d/0x630 ret_from_fork+0xef/0x1a0 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x33/0x60 kasan_record_aux_stack+0x8c/0xa0 __call_rcu_common.constprop.0+0x68/0x940 __schedule+0xff2/0x2930 __cond_resched+0x4c/0x80 mutex_lock+0x5c/0xe0 io_uring_del_tctx_node+0xe1/0x2b0 io_uring_clean_tctx+0xb7/0x160 io_uring_cancel_generic+0x34e/0x760 do_exit+0x240/0x2350 do_group_exit+0xab/0x220 __x64_sys_exit_group+0x39/0x40 x64_sys_call+0x1243/0x1840 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7f La dirección con errores pertenece al objeto en ffff88810de2cb00 que pertenece a la caché task_struct de tamaño 3712 La dirección con errores se encuentra 1992 bytes dentro de la región liberada de 3712 bytes [ffff88810de2cb00, ffff88810de2d980) que es causada por task_struct Al que apunta sq->thread, se libera mientras se usa en la función __io_uring_show_fdinfo(). Mantener ctx->uring_lock no impide la liberación ni la salida de sq->thread. Solucione esto asignando y buscando ->thread en RCU, y obteniendo una referencia a task_struct. Esto se trunca.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: ets: corrige una ejecución en ets_qdisc_change() Gerrard Tai informó de una condición de ejecución en ETS, siempre que el temporizador de perturbación SFQ se dispara en el momento equivocado. La ejecución es la siguiente: CPU 0 CPU 1 [1]: raíz de bloqueo [2]: qdisc_tree_flush_backlog() [3]: raíz de desbloqueo | | [5]: raíz de bloqueo | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() Esto se puede abusar para desbordar el qlen de un padre. Llamar a qdisc_purge_queue() en lugar de qdisc_tree_flush_backlog() debería corregir la ejecución, porque todos los paquetes se purgarán del qdisc antes de liberar el bloqueo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net_sched: red: corrige una ejecución en __red_change() Gerrard Tai informó una condición de ejecución en RED, siempre que el temporizador de perturbación SFQ se dispara en el momento equivocado. La carrera es la siguiente: CPU 0 CPU 1 [1]: raíz de bloqueo [2]: qdisc_tree_flush_backlog() [3]: raíz de desbloqueo | | [5]: raíz de bloqueo | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() Esto se puede abusar para desbordar el qlen de un padre. Llamar a qdisc_purge_queue() en lugar de qdisc_tree_flush_backlog() debería corregir la ejecución, porque todos los paquetes se purgarán del qdisc antes de liberar el bloqueo.

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.