Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: MGMT: rechazar comandos HCI_CMD_SYNC malformados En 'mgmt_hci_cmd_sync()', verifique si el tamaño de los parámetros pasados en 'struct mgmt_cp_hci_cmd_sync' coincide con el tamaño total de los datos (es decir, 'sizeof(struct mgmt_cp_hci_cmd_sync)' más los bytes finales). De lo contrario, un 'params_len' grande y no válido hará que 'hci_cmd_sync_alloc()' haga 'skb_put_data()' desde un área más allá de la que realmente se pasó a 'mgmt_hci_cmd_sync()'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: coresight: impide la desactivación de la configuración activa al habilitarla. Al habilitar la configuración activa mediante cscfg_csdev_enable_active_config(), esta podría desactivarse mediante la interfaz sysfs de configfs. Esto podría generar un problema de UAF en el siguiente escenario: CPU0 CPU1 (habilitación sysfs) carga el módulo cscfg_load_config_sets() activa la configuración. // sysfs (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config() lock(csdev->cscfg_csdev_lock) // aquí carga la configuración activada por CPU1 unlock(csdev->cscfg_csdev_lock) desactiva la configuración // sysfs (sys_activec_cnt == 0) cscfg_unload_config_sets() descarga el módulo // acceso a config_desc que se liberó // mientras se descargaba el módulo. cscfg_csdev_enable_config Para solucionar esto, utilice active_cnt de cscfg_config_desc como un recuento de referencia que se mantendrá cuando: - active la configuración. - habilite la configuración activada y coloque la referencia del módulo cuando config_active_cnt == 0.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: serial: Se corrige la posible desreferencia de puntero nulo en mlb_usio_probe(). devm_ioremap() puede devolver NULL en caso de error. Actualmente, mlb_usio_probe() no verifica este caso, lo que podría provocar una desreferencia de puntero NULL. Agregue una comprobación de NULL después de devm_ioremap() para evitar este problema.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ice: corrección del manejo de errores del programador de Tx en la devolución de llamada XDP. Al cargar el programa XDP, la devolución de llamada XDP añade nuevas colas de Tx. Esto significa que la devolución de llamada debe actualizar el programador de Tx con el nuevo número de cola. En caso de fallo del programador de Tx, la devolución de llamada XDP también debería fallar y revertir cualquier cambio realizado previamente para la preparación de XDP. La implementación anterior presentaba un error que impedía revertir todos los cambios realizados por la devolución de llamada XDP. Esto provocó el bloqueo con el siguiente seguimiento de llamada: [ +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5 [ +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI [ +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary) [ +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022 [ +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice] [...] [ +0.002715] Call Trace: [ +0.002452] [ +0.002021] ? __die_body.cold+0x19/0x29 [ +0.003922] ? die_addr+0x3c/0x60 [ +0.003319] ? exc_general_protection+0x17c/0x400 [ +0.004707] ? asm_exc_general_protection+0x26/0x30 [ +0.004879] ? __ice_update_sample+0x39/0xe0 [ice] [ +0.004835] ice_napi_poll+0x665/0x680 [ice] [ +0.004320] __napi_poll+0x28/0x190 [ +0.003500] net_rx_action+0x198/0x360 [ +0.003752] ? update_rq_clock+0x39/0x220 [ +0.004013] handle_softirqs+0xf1/0x340 [ +0.003840] ? sched_clock_cpu+0xf/0x1f0 [ +0.003925] __irq_exit_rcu+0xc2/0xe0 [ +0.003665] common_interrupt+0x85/0xa0 [ +0.003839] [ +0.002098] [ +0.002106] asm_common_interrupt+0x26/0x40 [ +0.004184] RIP: 0010:cpuidle_enter_state+0xd3/0x690. Para solucionar este problema, realice la desasignación de colas XDP de q_vectors y restablezca el puntero de anillos XDP a NULL después de liberar todas esas colas. Además, añada una salida inmediata de la devolución de llamada XDP en caso de un fallo en la preparación del anillo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: wwan: t7xx: Solución del problema de sondeo de napi rx. Cuando el controlador gestiona las solicitudes de sondeo de napi rx, es posible que la lógica dellink activada por la operación de desconexión en el plano de usuario haya liberado netdev. Sin embargo, en la lógica de procesamiento de skb en el sondeo, se sigue utilizando un netdev no válido, lo que provoca un pánico. ERROR: desreferencia de puntero nulo del kernel, dirección: 0000000000000f1 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:dev_gro_receive+0x3a/0x620 [...] Call Trace: ? __die_body+0x68/0xb0 ? page_fault_oops+0x379/0x3e0 ? exc_page_fault+0x4f/0xa0 ? asm_exc_page_fault+0x22/0x30 ? __pfx_t7xx_ccmni_recv_skb+0x10/0x10 [mtk_t7xx (HASH:1400 7)] ? dev_gro_receive+0x3a/0x620 napi_gro_receive+0xad/0x170 t7xx_ccmni_recv_skb+0x48/0x70 [mtk_t7xx (HASH:1400 7)] t7xx_dpmaif_napi_rx_poll+0x590/0x800 [mtk_t7xx (HASH:1400 7)] net_rx_action+0x103/0x470 irq_exit_rcu+0x13a/0x310 sysvec_apic_timer_interrupt+0x56/0x90

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: mld: evitar pánico en caso de fallo de inicialización. En caso de un error durante la inicialización, se establecerá in_hw_restart, pero nunca se borrará. En su lugar, volveremos a intentar la inicialización y luego actuaremos como si estuviéramos en un reinicio cuando en realidad no lo estamos. Esto provoca (entre otras cosas) una desreferencia de puntero NULL al cancelar rx_omi::finished_work, que ni siquiera se inicializó, porque creíamos que estábamos en hw_restart. Establezca in_hw_restart en verdadero solo si el firmware se está ejecutando; entonces, sabremos que el firmware se cargó correctamente y no entraremos en el bucle de reintentos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gve: se ha añadido la comprobación de valores nulos (NULL) faltante para gve_alloc_pending_packet() en TX DQO. gve_alloc_pending_packet() puede devolver valores nulos (NULL), pero gve_tx_add_skb_dqo() no los comprobaba antes de desreferenciar el puntero devuelto. Se ha añadido una comprobación de valores nulos (NULL) faltante para evitar una posible desreferencia de punteros nulos cuando falla la asignación. Esto mejora la robustez en escenarios con poca memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: asegúrese de que ptp_rate no sea 0 antes de configurar el sellado de tiempo. Los controladores de la plataforma stmmac que no incluyen en código abierto el valor clk_ptp_rate tras obtener el predeterminado del árbol de dispositivos pueden terminar con 0 en clk_ptp_rate (ya que clk_get_rate puede devolver 0). Esto se propagará hasta la inicialización de PTP al iniciar la interfaz, lo que provocará una división por 0: División por cero en el kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 No contaminado 6.12.30-00001-g48313bd5768a #22 Nombre del hardware: STM32 (Compatibilidad con árbol de dispositivos) Rastreo de llamadas: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x6c/0x8c dump_stack_lvl from Ldiv0_64+0x8/0x18 Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4 stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c stmmac_hw_setup from __stmmac_open+0x18c/0x434 __stmmac_open from stmmac_open+0x3c/0xbc stmmac_open from __dev_open+0xf4/0x1ac __dev_open from __dev_change_flags+0x1cc/0x224 __dev_change_flags from dev_change_flags+0x24/0x60 dev_change_flags from ip_auto_config+0x2e8/0x11a0 ip_auto_config from do_one_initcall+0x84/0x33c do_one_initcall from kernel_init_freeable+0x1b8/0x214 kernel_init_freeable from kernel_init+0x24/0x140 kernel_init from ret_from_fork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8) Evite esta división por 0 sumando Una comprobación explícita y un registro de errores sobre el problema. Mientras tanto, elimine la misma comprobación de stmmac_ptp_register, que se convierte en un duplicado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_set_pipapo_avx2: corrección del relleno inicial del mapa. Si el primer campo no cubre todo el mapa inicial, debemos poner a cero el resto; de lo contrario, filtraremos esos bits al mapa de la siguiente ronda de coincidencia. La corrección inicial estaba incompleta y solo corrigió la implementación genérica de C. Un parche posterior añade un caso de prueba a nft_concat_range.sh.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: stmmac: asegúrese de que ptp_rate no sea 0 antes de configurar EST Si el ptp_rate registrado anteriormente en el controlador resulta ser 0, este valor falso se propagará hasta la configuración de EST, donde activará una división por 0. Evite esta división por 0 agregando el código de verificación y error correspondiente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: fix udp gso skb_segment after pull from frag_list. El commit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation after pull from frag_list") detectó una geometría no válida en los skbs de frag_list y los redirige de skb_segment_list a un skb_segment más robusto. Sin embargo, algunos paquetes con geometría modificada también pueden presentar errores en ese código. Desconocemos cuántos casos de este tipo existen. Abordar cada uno por separado también requiere modificar el complejo código de skb_segment, lo que podría introducir errores en otros tipos de skbs. En su lugar, se linealizan todos los paquetes que no cumplen con las invariantes básicas en los skbs de fraglist gso. Esto es más robusto. Si solo se extrae una parte de el payload de fraglist en head_skb, siempre se generará una excepción al dividir los skbs por skb_segment. Para obtener información detallada de la pila de llamadas, consulte a continuación. SKB_GSO_FRAGLIST skbs válidos: constan de dos o más segmentos: head_skb contiene los encabezados de protocolo más el primer gso_size: uno o más frag_list skbs contienen exactamente un segmento; todos, excepto el último, deben ser gso_size Los ganchos de ruta de datos opcionales, como NAT y BPF (bpf_skb_pull_data), pueden modificar fraglist skbs, rompiendo estos invariantes. En casos extremos, extraen una parte de los datos en skb lineal. Para UDP, esto hace que se extraigan tres payloads con longitudes de (11,11,10) bytes para convertirse en (12,10,10) bytes. El skbs ya no cumple con las condiciones SKB_GSO_FRAGLIST anteriores porque el payload se extrajo en head_skb; debe linealizarse antes de pasarse a skb_segment regular. skb_segment+0xcd0/0xd14 __udp_gso_segment+0x334/0x5f4 udp4_ufo_fragment+0x118/0x15c inet_gso_segment+0x164/0x338 skb_mac_gso_segment+0xc4/0x13c __skb_gso_segment+0xc4/0x124 validate_xmit_skb+0x9c/0x2c0 validate_xmit_skb_list+0x4c/0x80 sch_direct_xmit+0x70/0x404 __dev_queue_xmit+0x64c/0xe5c neigh_resolve_output+0x178/0x1c4 ip_finish_output2+0x37c/0x47c __ip_finish_output+0x194/0x240 ip_finish_output+0x20/0xf4 ip_output+0x100/0x1a0 NF_HOOK+0xc4/0x16c ip_forward+0x314/0x32c ip_rcv+0x90/0x118 __netif_receive_skb+0x74/0x124 process_backlog+0xe8/0x1a4 __napi_poll+0x5c/0x1f8 net_rx_action+0x154/0x314 handle_softirqs+0x154/0x4b8 [118.376811] [C201134] rxq0_pus: [name:bug&]kernel BUG at net/core/skbuff.c:4278! [118.376829] [C201134] rxq0_pus: [name:traps&]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [118.470774] [C201134] rxq0_pus: [name:mrdump&]Kernel Offset: 0x178cc00000 from 0xffffffc008000000 [118.470810] [C201134] rxq0_pus: [name:mrdump&]PHYS_OFFSET: 0x40000000 [118.470827] [C201134] rxq0_pus: [name:mrdump&]pstate: 60400005 (nZCv daif +PAN -UAO) [118.470848] [C201134] rxq0_pus: [name:mrdump&]pc : [0xffffffd79598aefc] skb_segment+0xcd0/0xd14 [118.470900] [C201134] rxq0_pus: [name:mrdump&]lr : [0xffffffd79598a5e8] skb_segment+0x3bc/0xd14 [118.470928] [C201134] rxq0_pus: [name:mrdump&]sp : ffffffc008013770

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 ]