Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: xt_nfacct: no asuma que el nombre de la cuenta termina en nulo BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721 Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851 [..] string+0x231/0x2b0 lib/vsprintf.c:721 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874 [..] nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523 nfnl_acct_find_get() maneja entradas no nulas, pero el error printk dependía de su presencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: clk: davinci: Añadir comprobación de NULL en davinci_lpsc_clk_register(). Devm_kasprintf() devuelve NULL cuando falla la asignación de memoria. Actualmente, davinci_lpsc_clk_register() no comprueba este caso, lo que resulta en una desreferencia de puntero NULL. Añadir comprobación de NULL después de devm_kasprintf() para evitar este problema y garantizar que no queden recursos asignados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: power: supply: cpcap-charger: Se corrige la comprobación de valores nulos para power_supply_get_by_name. En la función cpcap_usb_detect(), la función power_supply_get_by_name() puede devolver `NULL` en lugar de un puntero de error. Para evitar posibles desreferencias de punteros nulos, se ha añadido una comprobación de valores nulos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: añadir una lógica de reintento en net6_rt_notify(). inet6_rt_notify() solo se puede ejecutar bajo la protección de RCU. Esto significa que la ruta podría modificarse simultáneamente y que rt6_fill_node() podría devolver -EMSGSIZE. Redimensione el skb cuando esto suceda y vuelva a intentarlo, eliminando un WARN_ON() que syzbot pudo activar: WARNING: CPU: 3 PID: 6291 at net/ipv6/route.c:6342 inet6_rt_notify+0x475/0x4b0 net/ipv6/route.c:6342 Modules linked in: CPU: 3 UID: 0 PID: 6291 Comm: syz.0.77 Not tainted 6.16.0-rc7-syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:inet6_rt_notify+0x475/0x4b0 net/ipv6/route.c:6342 Code: fc ff ff e8 6d 52 ea f7 e9 47 fc ff ff 48 8b 7c 24 08 4c 89 04 24 e8 5a 52 ea f7 4c 8b 04 24 e9 94 fd ff ff e8 9c fe 84 f7 90 <0f> 0b 90 e9 bd fd ff ff e8 6e 52 ea f7 e9 bb fb ff ff 48 89 df e8 RSP: 0018:ffffc900035cf1d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffffc900035cf540 RCX: ffffffff8a36e790 RDX: ffff88802f7e8000 RSI: ffffffff8a36e9d4 RDI: 0000000000000005 RBP: ffff88803c230f00 R08: 0000000000000005 R09: 00000000ffffffa6 R10: 00000000ffffffa6 R11: 0000000000000001 R12: 00000000ffffffa6 R13: 0000000000000900 R14: ffff888032ea4100 R15: 0000000000000000 FS: 00007fac7b89a6c0(0000) GS:ffff8880d6a20000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fac7b899f98 CR3: 0000000034b3f000 CR4: 0000000000352ef0 Call Trace: ip6_route_mpath_notify+0xde/0x280 net/ipv6/route.c:5356 ip6_route_multipath_add+0x1181/0x1bd0 net/ipv6/route.c:5536 inet6_rtm_newroute+0xe4/0x1a0 net/ipv6/route.c:5647 rtnetlink_rcv_msg+0x95e/0xe90 net/core/rtnetlink.c:6944 netlink_rcv_skb+0x155/0x420 net/netlink/af_netlink.c:2552 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x58d/0x850 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620

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.