Vulnerabilidades

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: 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: 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: 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: 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: 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: zloop: corrección del uso tras liberación de KASAN del conjunto de etiquetas. Al eliminar un dispositivo de bucle zonificado o un dispositivo zloop, el kernel habilitado para KASAN informa "BUG KASAN use after-free" en blk_mq_free_tag_set(). El error se produce porque zloop_ctl_remove() llama a put_disk(), que a su vez invoca zloop_free_disk(). zloop_free_disk() libera la memoria asignada al puntero zloop. Sin embargo, una vez liberada la memoria, zloop_ctl_remove() llama a blk_mq_free_tag_set(&zlo->tag_set), que accede al puntero zloop liberado. De ahí use-after-free de KASAN. Para evitar el error, mueva la llamada a blk_mq_free_tag_set(&zlo->tag_set) de zloop_ctl_remove() a zloop_free_disk(). Esto garantiza que el conjunto de etiquetas se libere antes de la llamada a kvfree(zlo).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: md: hacer que rdev_addable sea utilizable para el modo rcu Nuestro caso de prueba activa el pánico: ERROR: desreferencia de puntero NULL del kernel, dirección: 00000000000000e0 ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 No contaminado 6.16.0+ #94 PREEMPT(none) Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 01/04/2014 Cola de trabajo: md_misc md_start_sync RIP: 0010:rdev_addable+0x4d/0xf0 ... Rastreo de llamadas: Módulos vinculados en: raid10 CR2: 00000000000000e0 ---[ fin de seguimiento 000000000000000 ]--- RIP: 0010:rdev_addable+0x4d/0xf0 md_spares_need_change en md_start_sync llamará a rdev_addable que está protegido por rcu_read_lock/rcu_read_unlock. Este contexto rcu ayudará a proteger rdev, ya que no se liberará, pero rdev->mddev se establecerá en NULL antes de llamar a synchronize_rcu en md_kick_rdev_from_array. Para solucionar esto, use READ_ONCE y compruebe si rdev->mddev sigue activo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: descartar paquetes UFO en udp_rcv_segment() Al enviar un paquete con virtio_net_hdr a un dispositivo tun, si gso_type en virtio_net_hdr es SKB_GSO_UDP y gso_size es menor que el tamaño de udphdr, puede ocurrir el siguiente bloqueo. ------------[ cortar aquí ]------------ ¡ERROR del kernel en net/core/skbuff.c:4572! Oops: código de operación no válido: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 62 Comm: mytest No contaminado 6.16.0-rc7 #203 PREEMPT(voluntario) Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skb_pull_rcsum+0x8e/0xa0 Código: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000 RSP: 0018:ffffc900001fba38 EFLAGS: 00000297 RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948 RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062 RBP: ffff8880040c1000 R08: 000000000000000 R09: 0000000000000001 R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000 R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900 FS: 000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000080050033 CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0 Rastreo de llamadas: udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445 udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475 udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626 __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690 ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233 ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579 ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636 ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670 __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067 netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210 Para activar el segmento gso en udp_queue_rcv_skb(), también debemos configurar la opción UDP_ENCAP_ESPINUDP para habilitarla udp_sk(sk)->encap_rcv. Cuando el gancho encap_rcv devuelve 1 en udp_queue_rcv_one_skb(), udp_csum_pull_header() intentará extraer udphdr, pero el tamaño de skb se ha segmentado al tamaño de gso, lo que provoca este fallo. El commit anterior cf329aa42b66 ("udp: lidiar con la redirección de paquetes UDP GRO") introduce la segmentación en la ruta de recepción UDP solo para GRO, que nunca se concibió para UFO, por lo que se descartan los paquetes UFO en udp_rcv_segment().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PCI: pnv_php: Arreglar la detección y recuperación de conexiones sorpresivas El código de conexión en caliente PowerNV existente no manejaba correctamente los eventos de conexión sorpresiva, lo que provocaba un fallo completo del sistema de conexión en caliente tras la extracción del dispositivo y un reinicio necesario para detectar nuevos dispositivos. Esto se reduce a dos problemas: 1) Cuando se extrae un dispositivo por sorpresa, a menudo el puerto ascendente del puente provocará una congelación del PE en el PHB. Si esta congelación no se elimina, el kernel no recibirá las interrupciones MSI de la lógica de notificación de conexión en caliente del puente, lo que detendrá todos los eventos de conexión en todas las ranuras asociadas con el PE. 2) Cuando se extrae un dispositivo de una ranura, independientemente de si es una extracción sorpresiva o programática, el PHB/PE asociado queda congelado. Si esta congelación no se elimina mediante un reinicio fundamental, skiboot no puede eliminar la congelación y no puede volver a entrenar/escanear la ranura. Esto también requiere un reinicio para eliminar la congelación y volver a detectar el dispositivo en la ranura. Emita los comandos de descongelación y reescaneo adecuados en eventos de conexión en caliente, y no falle en la conexión en caliente si pci_bus_to_OF_node() devuelve NULL. [bhelgaas: comentarios ordenados]