Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pinmux: corrección de la carrera que causaba que mux_owner fuera nulo con el commit 5a3e85c3c397 de mux_usecount activa ("pinmux: Usar acceso secuencial para acceder a los datos de desc->pinmux"). Se intentó solucionar el problema cuando dos clientes del mismo GPIO llamaban a pinctrl_select_state() para la misma funcionalidad, lo que provocaba un problema de puntero nulo al acceder a desc->mux_owner. Sin embargo, el problema no se solucionó por completo debido a la forma en que se gestionó y aún puede resultar en el mismo puntero nulo. El problema se produce debido a la siguiente intercalación: cpu0 (proceso A) cpu1 (proceso B) pin_request() { pin_free() { mutex_lock() desc->mux_usecount--; //se convierte en 0 .. mutex_unlock() mutex_lock(desc->mux) desc->mux_usecount++; // se convierte en 1 desc->mux_owner = owner; mutex_unlock(desc->mux) mutex_lock(desc->mux) desc->mux_owner = NULL; mutex_unlock(desc->mux) Esta secuencia lleva a un estado donde el pin parece estar en uso (`mux_usecount == 1`) pero no tiene propietario (`mux_owner == NULL`), lo que puede generar un puntero nulo en la siguiente solicitud de pin en el mismo pin. Asegúrese de que las actualizaciones de mux_usecount y mux_owner se realicen automáticamente bajo el mismo bloqueo. Solo borre mux_owner cuando mux_usecount llegue a cero y no se haya asignado un nuevo propietario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: spacemit: marcar K1 pll1_d8 como crítico El reloj pll1_d8 es habilitado por el gestor de arranque y, en última instancia, es un reloj padre para numerosos relojes, incluidos los que utilizan los buses APB y AXI. Guodong Xu descubrió que este reloj se deshabilitaba al responder a la obtención de -EPROBE_DEFER al solicitar un controlador de reinicio. El reloj necesario (CLK_DMA, junto con sus padres) ya se había habilitado. Para responder al retorno de aplazamiento de la sonda, se deshabilitó el reloj CLK_DMA, y esto provocó que los relojes padre también redujeran su contador de habilitaciones. Cuando se decrementó el contador de habilitaciones para pll1_d8, se convirtió en 0, lo que provocó que se deshabilitara. Esto provocó un cuelgue del sistema. Marcar ese reloj como crítico resuelve esto evitando que se deshabilite. Defina una nueva macro CCU_FACTOR_GATE_DEFINE() para permitir que se suministren indicadores de reloj para un reloj CCU_FACTOR_GATE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rv: Uso de cadenas en los puntos de seguimiento de los monitores DA El uso de puntos de seguimiento de los monitores DA con KASAN habilitado activa la siguiente advertencia: ERROR: KASAN: global fuera de los límites en do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 Lectura de tamaño 32 en la dirección ffffffffaada8980 por la tarea ... Seguimiento de llamada: [...] do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0 ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10 ? trace_event_sncid+0x83/0x200 trace_event_sncid+0x163/0x200 [...] La dirección con errores pertenece a la variable: automaton_snep+0x4e0/0x5e0 Esto se debe a que los puntos de seguimiento leen 32 bytes __array en lugar de __string de la definición del autómata. Dichas cadenas son literales y la lectura de 32 bytes termina en accesos fuera de memoria límite (por ejemplo, los datos del siguiente autómata en este caso). El error es inofensivo ya que, al imprimir la cadena, nos detenemos en el terminador nulo, pero aún así debería corregirse. Use las facilidades __string al definir los puntos de seguimiento para evitar la lectura fuera de memoria límite.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: imxfb: Comprobar fb_add_videomode para evitar la desreferencia de PTR nula. fb_add_videomode() puede fallar con -ENOMEM cuando su función interna kmalloc() no puede asignar una estructura fb_modelist. En tal caso, la estructura de modelist permanece vacía, pero el controlador continúa registrándose. Se ha añadido una comprobación de su valor de retorno para evitar una posible desreferencia de PTR nula, similar al commit 17186f1f90d3 ("fbdev: Corregir do_register_framebuffer para evitar la desreferencia de PTR nula en fb_videomode_to_var").

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfio/pds: Se ha corregido la operación detach_ioas que faltaba. Cuando CONFIG_IOMMUFD está habilitado y un dispositivo está enlazado al controlador pds_vfio_pci, se observa el siguiente rastro WARN_ON() y la sonda falla: WARNING: CPU: 0 PID: 5040 at drivers/vfio/vfio_main.c:317 __vfio_register_dev+0x130/0x140 [vfio] <...> pds_vfio_pci 0000:08:00.1: la sonda con el controlador pds_vfio_pci falló con el error -22. Esto se debe a que vfio_device_ops.detach_ioas del controlador no está configurado. Solucione esto usando la función genérica vfio_iommufd_physical_detach_ioas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para activar el gc de primer plano durante f2fs_map_blocks() en modo lfs con la opción de montaje "mode=lfs", generic/299 provocará pánico en el sistema como se muestra a continuación: ------------[ cortar aquí ]------------ ¡ERROR del kernel en fs/f2fs/segment.c:2835! Rastreo de llamadas: f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720 La causa principal de la falta de espacio es que, en f2fs_map_blocks(), f2fs puede activar el recolector de basura en primer plano solo si asigna algún bloque físico. Esto ocurrirá un poco más tarde, cuando varios subprocesos escriban datos con el método aio/dio/bufio en paralelo. Dado que siempre usamos OPU en modo lfs, f2fs_map_blocks() realiza asignaciones de bloques de forma agresiva. Para solucionar este problema, permitamos que el recolector de basura en primer plano se active antes de la asignación de bloques en f2fs_map_blocks().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vdpa/mlx5: Corrección de la liberación de recursos no inicializados en la ruta de error el commit en la etiqueta fixes aseguró que mlx5_vdpa_free() sea el único punto de entrada para eliminar los recursos del dispositivo vdpa agregados en mlx5_vdpa_dev_add(), incluso en la ruta de limpieza de mlx5_vdpa_dev_add(). Esto significa que todas las funciones de mlx5_vdpa_free() deberían poder manejar recursos no inicializados. Sin embargo, este no fue el caso: mlx5_vdpa_destroy_mr_resources() y mlx5_cmd_cleanup_async_ctx() no pudieron hacerlo. Esto causó el splat a continuación al agregar un dispositivo vdpa sin una dirección MAC. Este parche corrige estos problemas restantes: - Hace que mlx5_vdpa_destroy_mr_resources() regrese antes si se llama en recursos no inicializados. - Se mueve mlx5_cmd_init_async_ctx() al principio de la adición del dispositivo, ya que no puede fallar. Esto significa que mlx5_cmd_cleanup_async_ctx() tampoco puede fallar. Para reflejar esto, mueva el sitio de llamada de mlx5_cmd_cleanup_async_ctx() a mlx5_vdpa_free(). Se añadió un comentario adicional en mlx5_vdpa_free() para documentar las expectativas de las funciones llamadas desde este contexto. Splat: mlx5_core 0000:b5:03.2: mlx5_vdpa_dev_add:3950:(pid 2306) advertencia: ¿No se ha proporcionado ninguna dirección MAC? ------------[ cortar aquí ]------------ ADVERTENCIA: CPU: 13 PID: 2306 en kernel/workqueue.c:4207 __flush_work+0x9a/0xb0 [...] Rastreo de llamadas: ? __try_to_del_timer_sync+0x61/0x90 ? __timer_delete_sync+0x2b/0x40 mlx5_vdpa_destroy_mr_resources+0x1c/0x40 [mlx5_vdpa] mlx5_vdpa_free+0x45/0x160 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x327/0x890 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x2c1/0x4d0 [vdpa] genl_family_rcv_msg_doit+0xd8/0x130 genl_family_rcv_msg+0x14b/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] genl_rcv_msg+0x47/0xa0 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x27b/0x3b0 netlink_sendmsg+0x1f7/0x430 __sys_sendto+0x1fa/0x210 ? ___pte_offset_map+0x17/0x160 ? next_uptodate_folio+0x85/0x2b0 ? percpu_counter_add_batch+0x51/0x90 ? filemap_map_pages+0x515/0x660 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x7b/0x2c0 ? do_read_fault+0x108/0x220 ? do_pte_missing+0x14a/0x3e0 ? __handle_mm_fault+0x321/0x730 ? count_memcg_events+0x13f/0x180 ? handle_mm_fault+0x1fb/0x2d0 ? do_user_addr_fault+0x20c/0x700 ? syscall_exit_work+0x104/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f0c25b0feca [...] ---[ fin de seguimiento 0000000000000000 ]---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ALSA: usb: scarlett2: Se corrige la falta de comprobación de valores NULL. scarlett2_input_select_ctl_info() configura las matrices de cadenas asignadas mediante kasprintf(), pero omite las comprobaciones de valores NULL, lo que puede provocar una desreferencia de valores NULL. ¡Uy! Añadamos la comprobación de valores NULL adecuada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: imx95-blk-ctl: Corregir aborto sincrónico. Al habilitar PM en tiempo de ejecución para proveedores de reloj que también pertenecen a un dominio de energía, se produce el siguiente fallo: error: aborto externo sincrónico: 0000000096000010 [#1] PREEMPT SMP Workqueue: events_unbound deferred_probe_work_func pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : clk_mux_get_parent+0x60/0x90 lr : clk_core_reparent_orphans_nolock+0x58/0xd8 Rastreo de llamadas: clk_mux_get_parent+0x60/0x90 clk_core_reparent_orphans_nolock+0x58/0xd8 of_clk_add_hw_provider.part.0+0x90/0x100 of_clk_add_hw_provider+0x1c/0x38 imx95_bc_probe+0x2e0/0x3f0 platform_probe+0x70/0xd8 Al habilitar el PM en tiempo de ejecución sin reanudar explícitamente el dispositivo, se interrumpió el dominio de energía después de llamar a clk_register(). Como resultado, se produce un fallo cuando se agrega el proveedor de hardware de reloj e intenta acceder al registro BLK_CTL. Para solucionar esto, use devm_pm_runtime_enable() en lugar de pm_runtime_enable() y elimine pm_runtime_disable() en la ruta de limpieza.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: compress: fix UAF de f2fs_inode_info en f2fs_free_dic El decompress_io_ctx puede liberarse de forma asíncrona tras la finalización de la E/S. Si este archivo se elimina inmediatamente después de la lectura, y el kworker del procesamiento de post_read_wq aún no se ha ejecutado debido a las altas cargas de trabajo, es posible que el inodo (f2fs_inode_info) se desaloje y se libere antes de que se use f2fs_free_dic. El caso de UAF como se muestra a continuación: Hilo A Hilo B - f2fs_decompress_end_io - f2fs_put_dic - queue_work añadir trabajo free_dic a post_read_wq - do_unlink - iput - evict - call_rcu Este archivo se elimina tras la lectura. Hilo C kworker para procesar post_read_wq - rcu_do_batch - f2fs_free_inode - kmem_cache_free inodo liberado por rcu - process_scheduled_works - f2fs_late_free_dic - f2fs_free_dic - f2fs_release_decomp_mem lectura (dic->inode)->i_compress_algorithm). Este parche almacena compress_algorithm y sbi en dic para evitar el UAF del inodo. Además, la solución anterior está obsoleta en [1] y puede causar un bloqueo del sistema. [1] https://lore.kernel.org/all/c36ab955-c8db-4a8b-a9d0-f07b5f426c3f@kernel.org

En mupen64plus v2.6.0 hay una vulnerabilidad de desbordamiento de matriz en las funciones write_rdram_regs y write_rdram_regs, que permite ejecutar comandos arbitrarios en la máquina host.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: pnv_php: Limpiar las IRQ asignadas al desconectar Cuando se desconecta la raíz de una configuración de puente PCIe anidada, el controlador pnv_php filtró los recursos IRQ asignados para las notificaciones de eventos de conexión en caliente de los puentes secundarios, lo que resultó en un pánico. Corrija esto recorriendo todos los buses secundarios y desasignando todos sus recursos IRQ antes de llamar a pci_hp_remove_devices(). También modifique el tiempo de vida de la cola de trabajo en struct pnv_php_slot::wq para que solo se destruya en pnv_php_free_slot(), en lugar de pnv_php_disable_irq(). Esto es necesario ya que pnv_php_disable_irq() ahora será llamado por trabajadores activados por interrupciones de desconexión en caliente, por lo que la cola de trabajo debe permanecer asignada. El pánico del kernel abreviado que ocurre sin este parche es el siguiente: ADVERTENCIA: CPU: 0 PID: 687 en kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash No contaminado 6.14.0-rc5+ #2 Seguimiento de llamadas: msi_device_data_release+0x34/0x9c (no confiable) release_nodes+0x64/0x13c devres_release_all+0xc0/0x140 device_del+0x2d4/0x46c pci_destroy_dev+0x5c/0x194 pci_hp_remove_devices+0x90/0x128 pci_hp_remove_devices+0x44/0x128 pnv_php_disable_slot+0x54/0xd4 power_write_file+0xf8/0x18c pci_ranura_attr_store+0x40/0x5c sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x3bc/0x50c ksys_write+0x84/0x140 system_call_exception+0x124/0x230 system_call_vectored_common+0x15c/0x2ec [bhelgaas: comentarios ordenados]