Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: corrección de WARN_ON para el modo monitor en algunos dispositivos. En dispositivos sin WANT_MONITOR_VIF (y probablemente sin compatibilidad con contexto de canal), recibimos un WARN_ON al cambiar la configuración por enlace de una interfaz de monitor. Dado que ya omitimos las interfaces AP_VLAN y MONITOR con WANT_MONITOR_VIF o NO_VIRTUAL_MONITOR debería actualizar la configuración, se debe incluir esto en el código de cambio de enlace en lugar de la advertencia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtw89: evitar la desreferencia NULL al recibir un paquete problemático en una banda de 6 GHz no compatible. En raras ocasiones, el informe de recepción podría ser problemático al hacer que el software piense que se recibe un paquete en la banda de 6 GHz, incluso si el chip no la admite. Dado que el software no inicializa elementos para bandas no compatibles, se producirá una desreferencia NULL en la secuencia rtw89_vif_rx_stats_iter() -> rtw89_core_cancel_6ghz_probe_tx(). Por lo tanto, se debe añadir una comprobación para evitarlo. A continuación, se muestra un registro de fallos para este caso. ERROR: desreferencia de puntero NULL del kernel, dirección: 0000000000000032 #PF: acceso de lectura del supervisor en modo kernel #PF: error_code(0x0000) - página no presente PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1907 Comm: irq/131-rtw89_p Tainted: GU 6.6.56-05896-g89f5fb0eb30b #1 (HASH:1400 4) Nombre del hardware: Google Telith/Telith, BIOS Google_Telith.15217.747.0 11/12/2024 RIP: 0010:rtw89_vif_rx_stats_iter+0xd2/0x310 [rtw89_core] Código: 4c 89 7d c8 48 89 55 c0 49 8d 44 24 02 48 89 45 b8 45 31 ff eb 11 41 c6 45 3a 01 41 b7 01 4d 8b 6d 00 4d 39 f5 74 42 8b 43 10 <41> 33 45 32 0f b7 4b 14 66 41 33 4d 36 0f b7 c9 09 c1 74 d8 4d 85 RSP: 0018:ffff9f3080138ca0 EFLAGS: 00010246 RAX: 00000000b8bf5770RBX: ffff91b5e8c639c0 RCX: 00000000000000011 RDX: ffff91b582de1be8 RSI: 0000000000000000 RDI: ffff91b5e8c639e6 RBP: ffff9f3080138d00 R08: 0000000000000000 R09: 00000000000000000 R10: ffff91b59de70000 R11: ffffffffc069be50 R12: ffff91b5e8c639e4 R13: 0000000000000000 R14: ffff91b5828020b8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff91b8efa40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000032 CR3: 00000002bf838000 CR4: 0000000000750ee0 PKRU: 55555554 Rastreo de llamadas: ? __die_body+0x68/0xb0 ? error_página_oops+0x379/0x3e0 ? error_página_oops+0x4f/0xa0 ? error_página_oops+0x22/0x30 ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [núcleo_rtw89 (HASH:1400 5)] ? rtw89_vif_rx_stats_iter+0xd2/0x310 [núcleo_rtw89 (HASH:1400 5)] __iterate_interfaces+0x59/0x110 [mac80211 (HASH:1400 6)] ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [núcleo rtw89 (HASH:1400 5)] ? __pfx_rtw89_vif_rx_stats_iter+0x10/0x10 [núcleo rtw89 (HASH:1400 5)] ieee80211_iterar_interfaces_activas_atómicas+0x36/0x50 [mac80211 (HASH:1400 6)] rtw89_núcleo_rx_a_mac80211+0xfd/0x1b0 [núcleo rtw89 (HASH:1400 5)] rtw89_núcleo_rx+0x43a/0x980 [núcleo rtw89 (HASH:1400 5)]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: Se ha añadido un bloqueo faltante en cfg80211_check_and_end_cac(). Quienes llaman a wdev_chandef() deben mantener el mutex de wiphy. Sin embargo, el trabajador cfg80211_propagate_cac_done_wk() nunca asume el bloqueo. Lo que activa la advertencia a continuación con la prueba mesh_peer_connected_dfs de hostapd y los cambios de código mac80211 no publicados (aún): ADVERTENCIA: CPU: 0 PID: 495 en net/wireless/chan.c:1552 wdev_chandef+0x60/0x165 Módulos vinculados: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 No contaminado 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Cola de trabajo: cfg80211 cfg80211_propagate_cac_done_wk Pila: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Rastreo de llamadas: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] proceso_trabajos_programados+0x3bc/0x60e [<6007d0ec>] ? mover_trabajos_vinculados+0x4d/0x81 [<6007d120>] ? asignar_trabajo+0x0/0xaa [<6007f81f>] subproceso_trabajador+0x220/0x2dc [<600786ef>] ? establecer_pf_trabajador+0x0/0x57 [<60087c96>] ? hilo_trabajador+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64 marca de evento de irq: 614611 hardirqs habilitados por última vez en (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xaf hardirqs deshabilitados por última vez en (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xaf softirqs habilitados por última vez en (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985 softirqs deshabilitados por última vez en (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985

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.