Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: MGMT: Reparar UAF en mgmt_remove_adv_monitor_complete Esto reelabora MGMT_OP_REMOVE_ADV_MONITOR para que no use mgmt_pending_add para evitar fallos como los siguientes: ===================================================================== ERROR: KASAN: slab-use-after-free en mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406 Lectura de tamaño 8 en la dirección ffff88801c53f318 por la tarea kworker/u5:5/5341 CPU: 0 UID: 0 PID: 5341 Comm: kworker/u5:5 No contaminado 6.15.0-syzkaller-10402-g4cb6c8af8591 #0 PREEMPT(full) Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 01/04/2014 Cola de trabajo: hci0 hci_cmd_sync_work Rastreo de llamadas: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406 hci_cmd_sync_work+0x261/0x3a0 net/bluetooth/hci_sync.c:334 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 5987: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] mgmt_pending_new+0x65/0x240 net/bluetooth/mgmt_util.c:252 mgmt_pending_add+0x34/0x120 net/bluetooth/mgmt_util.c:279 remove_adv_monitor+0x103/0x1b0 net/bluetooth/mgmt.c:5454 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x548/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5989: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2380 [inline] slab_free mm/slub.c:4642 [inline] kfree+0x18e/0x440 mm/slub.c:4841 mgmt_pending_foreach+0xc9/0x120 net/bluetooth/mgmt_util.c:242 mgmt_index_removed+0x10d/0x2f0 net/bluetooth/mgmt.c:9366 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314 __sys_bind_socket net/socket.c:1810 [inline] __sys_bind+0x2c3/0x3e0 net/socket.c:1841 __do_sys_bind net/socket.c:1846 [inline] __se_sys_bind net/socket.c:1844 [inline] __x64_sys_bind+0x7a/0x90 net/socket.c:1844 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

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.