Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: PM/devfreq: Comprobar el gobernador antes de usar governor->name. El commit 96ffcdf239de ("PM/devfreq: Eliminar el nombre redundante de governor_name de la estructura devfreq") elimina governor_name y usa governor->name para reemplazarlo. Sin embargo, devfreq->governor podría ser NULL y usar directamente devfreq->governor->name podría causar una excepción de puntero nulo. Se debe mover la comprobación del gobernador a antes de usar governor->name.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, ktls: Se corrige la corrupción de datos al usar bpf_msg_pop_data() en ktls. Al enviar datos de texto plano, inicialmente se calculaba la longitud del texto cifrado correspondiente. Sin embargo, si posteriormente se reducía la longitud de los datos de texto plano mediante la política de socket, no se podía recalcular la longitud del texto cifrado. Esto provoca que se transmitan búferes con datos sin inicializar durante la transmisión del texto cifrado. Esto provoca que se añadan bytes sin inicializar después de un paquete completo de "Datos de Aplicación", lo que genera errores en el receptor al analizar el registro TLS.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: manejar jset (si a & b ...) como un salto en el cálculo CFG. BPF_JSET es un salto condicional y actualmente verifier.c:can_jump() no lo detecta. Esto puede provocar registros activos y cálculos SCC incorrectos. Por ejemplo, en el siguiente ejemplo: 1: r0 = 1; 2: r2 = 2; 3: si r1 & 0x7 goto +1; 4: salir; 5: r0 = r2; 6: salir; Sin esta corrección, insn_successors(3) solo devolverá (4), se omitiría un salto a (5) y r2 no se marcaría como activo en (3).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: staging: gpib: corrección de la copia de un campo de relleno no asignado al espacio de usuario. La introducción de un campo de relleno en gpib_board_info_ioctl se muestra como datos inicializados en el frame de pila que se copian al espacio de usuario en la función board_info_ioctl. La solución más sencilla es inicializar toda la estructura a cero para garantizar que todos los campos de relleno no asignados se restablezcan a cero antes de copiarse al espacio de usuario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdgpu: corrección de slab-use-after-free en amdgpu_userq_mgr_fini+0x70c. El problema se reprodujo en NV10 mediante la prueba pci_unplug de IGT. Se espera que `amdgpu_driver_postclose_kms()` se llame antes que `amdgpu_drm_release()`. Sin embargo, el error radica en que `amdgpu_fpriv` se liberó en `amdgpu_driver_postclose_kms()` y luego se accedió a él en `amdgpu_drm_release()` mediante una llamada a `amdgpu_userq_mgr_fini()`. Como resultado, KASAN detectó una condición de use-after-free, como se muestra en el registro a continuación. La solución propuesta es mover las llamadas a `amdgpu_eviction_fence_destroy()` y `amdgpu_userq_mgr_fini()` a `amdgpu_driver_postclose_kms()`, de modo que se invoquen antes de que se libere `amdgpu_fpriv`. Esto también garantiza la simetría con la ruta de inicialización en `amdgpu_driver_open_kms()`, donde se inicializan los siguientes componentes: - `amdgpu_userq_mgr_init()` - `amdgpu_eviction_fence_init()` - `amdgpu_ctx_mgr_init()` En consecuencia, en `amdgpu_driver_postclose_kms()` debemos limpiar usando: - `amdgpu_userq_mgr_fini()` - `amdgpu_eviction_fence_destroy()` - `amdgpu_ctx_mgr_fini()` Este cambio elimina el use-after-free y mejora la consistencia en la gestión de recursos entre las rutas de apertura y cierre. [ +0.094367] ====================================================================== [ +0.000026] ERROR: KASAN: slab-use-after-free in amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000866] Write of size 8 at addr ffff88811c068c60 by task amd_pci_unplug/1737 [ +0.000026] CPU: 3 UID: 0 PID: 1737 Comm: amd_pci_unplug Not tainted 6.14.0+ #2 [ +0.000008] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000004] Call Trace: [ +0.000004] [ +0.000003] dump_stack_lvl+0x76/0xa0 [ +0.000010] print_report+0xce/0x600 [ +0.000009] ? amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000790] ? srso_return_thunk+0x5/0x5f [ +0.000007] ? kasan_complete_mode_report_info+0x76/0x200 [ +0.000008] ? amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000684] kasan_report+0xbe/0x110 [ +0.000007] ? amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000601] __asan_report_store8_noabort+0x17/0x30 [ +0.000007] amdgpu_userq_mgr_fini+0x70c/0x730 [amdgpu] [ +0.000801] ? __pfx_amdgpu_userq_mgr_fini+0x10/0x10 [amdgpu] [ +0.000819] ? srso_return_thunk+0x5/0x5f [ +0.000008] amdgpu_drm_release+0xa3/0xe0 [amdgpu] [ +0.000604] __fput+0x354/0xa90 [ +0.000010] __fput_sync+0x59/0x80 [ +0.000005] __x64_sys_close+0x7d/0xe0 [ +0.000006] x64_sys_call+0x2505/0x26f0 [ +0.000006] do_syscall_64+0x7c/0x170 [ +0.000004] ? kasan_record_aux_stack+0xae/0xd0 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? kmem_cache_free+0x398/0x580 [ +0.000006] ? __fput+0x543/0xa90 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __fput+0x543/0xa90 [ +0.000004] ? __kasan_check_read+0x11/0x20 [ +0.000007] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? __kasan_check_read+0x11/0x20 [ +0.000003] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? fpregs_assert_state_consistent+0x21/0xb0 [ +0.000006] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? syscall_exit_to_user_mode+0x4e/0x240 [ +0.000005] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? do_syscall_64+0x88/0x170 [ +0.000003] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? do_syscall_64+0x88/0x170 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? irqentry_exit+0x43/0x50 [ +0.000004] ? srso_return_thunk+0x5/0x5f [ +0.000004] ? exc_page_fault+0x7c/0x110 [ +0.000006] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000005] RIP: 0033:0x7ffff7b14f67 [ +0.000005] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff [ +0.000004] RSP: 002b:00007fffffffe358 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ +0.000006] RAX: ffffffffff ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: rtl818x: Eliminar URBs antes de borrar la cola de estado de la transmisión. En rtl8187_stop(), la llamada a usb_kill_anchored_urbs() se desplaza antes de borrar b_tx_status.queue. Este cambio impide que las devoluciones de llamada utilicen skb ya liberados, ya que el ancla no se eliminó antes de liberar dicho skb. ERROR: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211] Call Trace: rtl8187_tx_cb+0x116/0x150 [rtl8187] __usb_hcd_giveback_urb+0x9d/0x120 usb_giveback_urb_bh+0xbb/0x140 process_one_work+0x19b/0x3c0 bh_worker+0x1a7/0x210 tasklet_action+0x10/0x30 handle_softirqs+0xf0/0x340 __irq_exit_rcu+0xcd/0xf0 common_interrupt+0x85/0xa0 Probado en el dispositivo RTL8187BvE. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iwlwifi: Agregar verificación faltante para alloc_ordered_workqueue Agregar verificación para el valor de retorno de alloc_ordered_workqueue ya que puede devolver un puntero NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath11k: borrar el indicador inicializado para listas srng desiniciadas En varios casos, vemos pánicos del kernel al reanudarse debido a un fallo de página del kernel ath11k, que sucede en las siguientes circunstancias: 1) Primera llamada a ath11k_hal_dump_srng_stats() Última interrupción recibida para cada grupo: ath11k_pci 0000:01:00.0: group_id 0 22511ms antes ath11k_pci 0000:01:00.0: group_id 1 14440788ms antes [..] ath11k_pci 0000:01:00.0: no se pudo recibir la respuesta de control finalización, sondeo.. ath11k_pci 0000:01:00.0: tiempo de espera de conexión del servicio ath11k_pci 0000:01:00.0: no se pudo conectar a HTT: -110 ath11k_pci 0000:01:00.0: no se pudo iniciar el núcleo: -110 ath11k_pci 0000:01:00.0: el firmware falló: MHI_CB_EE_RDDM ath11k_pci 0000:01:00.0: ya se está restableciendo el recuento 2 ath11k_pci 0000:01:00.0: no se pudo esperar la solicitud de modo wlan (modo 4): -110 ath11k_pci 0000:01:00.0: qmi no pudo enviar el modo wlan desactivado: -110 ath11k_pci 0000:01:00.0: no se pudo reconfigurar el controlador en la recuperación de falla [..] 2) En este punto, la reconfiguración falla (tenemos 2 Se reinicia) y ath11k_core_reconfigure_on_crash() llama a ath11k_hal_srng_deinit(), que destruye las listas srng. Sin embargo, no reinicia el indicador de inicialización por lista. 3) La segunda llamada ath11k_hal_dump_srng_stats() ve la bandera obsoleta ->inicializada e intenta volcar las estadísticas de srng: Última interrupción recibida para cada grupo: ath11k_pci 0000:01:00.0: group_id 0 66785ms antes ath11k_pci 0000:01:00.0: group_id 1 14485062ms antes ath11k_pci 0000:01:00.0: group_id 2 14485062ms antes ath11k_pci 0000:01:00.0: group_id 3 14485062ms antes ath11k_pci 0000:01:00.0: group_id 4 14780845ms antes ath11k_pci 0000:01:00.0: group_id 5 14780845ms antes ath11k_pci 0000:01:00.0: group_id 6 14485062ms antes ath11k_pci 0000:01:00.0: group_id 7 66814ms antes ath11k_pci 0000:01:00.0: group_id 8 68997ms antes ath11k_pci 0000:01:00.0: group_id 9 67588ms antes ath11k_pci 0000:01:00.0: group_id 10 69511ms antes ERROR: no se puede manejar el error de página para la dirección: ffffa007404eb010 #PF: lectura del supervisor acceso en modo kernel #PF: error_code(0x0000) - página no presente PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k] Seguimiento de llamadas: ? __die_body+0xae/0xb0 ? page_fault_oops+0x381/0x3e0 ? exc_page_fault+0x69/0xa0 ? asm_exc_page_fault+0x22/0x30 ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)] ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)] worker_thread+0x389/0x930 kthread+0x149/0x170 Limpiar la bandera por lista ->inicializada en ath11k_hal_srng_deinit().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Evitar el acceso arvif->ar no inicializado durante un fallo de baliza. Durante la gestión de fallos de baliza, el controlador ath12k itera sobre interfaces virtuales activas (VIF) e intenta acceder al objeto de radio (AR) mediante arvif->deflink->ar. Sin embargo, tras el commit aa80f12f3bed ("wifi: ath12k: aplazar la creación de VDEV para MLO"), arvif se vincula a una radio solo después de la creación de VDEV, normalmente cuando se asigna un canal o se solicita un escaneo. Para dispositivos con capacidad P2P, wpa_supplicant crea una interfaz P2P predeterminada junto con las interfaces de estación normales. Estas sirven como interfaces ficticias para estaciones con capacidad P2P, carecen de un netdev asociado e inician escaneos frecuentes para descubrir dispositivos P2P vecinos. Al iniciar un escaneo en estos vifs P2P, el controlador selecciona la radio de destino (ar) según su frecuencia, crea un vdev de escaneo y asocia el arvif a la radio. Una vez que el escaneo se completa o se aborta, el vdev de escaneo se elimina, desconectando el arvif de la radio y dejando el archivo arvif->ar sin inicializar. Al gestionar fallos de baliza para las interfaces de estación, también se encuentra la interfaz P2P en la iteración del vif y ath12k_mac_handle_beacon_miss_iter() intenta desreferenciar el archivo arvif->deflink->ar sin inicializar. Para solucionar esto, verifique que el vdev se haya creado para el arvif antes de acceder a su ar durante la gestión de fallos de baliza y devoluciones de llamada similares del iterador vif. ============================================================================ wlp6s0: se detectó pérdida de baliza del AP (7 balizas perdidas) - sondeando KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 5 UID: 0 PID: 0 Comm: swapper/5 Not tainted 6.16.0-rc1-wt-ath+ #2 PREEMPT(full) RIP: 0010:ath12k_mac_handle_beacon_miss_iter+0xb5/0x1a0 [ath12k] Call Trace: __iterate_interfaces+0x11a/0x410 [mac80211] ieee80211_iterate_active_interfaces_atomic+0x61/0x140 [mac80211] ath12k_mac_handle_beacon_miss+0xa1/0xf0 [ath12k] ath12k_roam_event+0x393/0x560 [ath12k] ath12k_wmi_op_rx+0x1486/0x28c0 [ath12k] ath12k_htc_process_trailer.isra.0+0x2fb/0x620 [ath12k] ath12k_htc_rx_completion_handler+0x448/0x830 [ath12k] ath12k_ce_recv_process_cb+0x549/0x9e0 [ath12k] ath12k_ce_per_engine_service+0xbe/0xf0 [ath12k] ath12k_pci_ce_workqueue+0x69/0x120 [ath12k] process_one_work+0xe3a/0x1430 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00284.1-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7925: corrección de uno en mt7925_mcu_hw_scan() Las matrices ssid->ssids[] y sreq->ssids[] tienen elementos MT7925_RNR_SCAN_MAX_BSSIDS, por lo que esto >= debe ser > para evitar un acceso fuera de los límites.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath12k: Pasar el puntero ab directamente a ath12k_dp_tx_get_encap_type(). En ath12k_dp_tx_get_encap_type(), el parámetro arvif solo se usa para recuperar el puntero ab. En la secuencia de eliminación de vdev, arvif->ar podría volverse nulo, lo que provocaría un pánico del kernel. Dado que el llamador ath12k_dp_tx() ya tiene un puntero ab válido, páselo directamente para evitar el pánico y la desreferenciación innecesaria. El PC apunta a "ath12k_dp_tx+0x228/0x988 [ath12k]". El LR apunta a "ath12k_dp_tx+0xc8/0x988 [ath12k]". El backtrace obtenido es el siguiente: ath12k_dp_tx+0x228/0x988 [ath12k] ath12k_mac_tx_check_max_limit+0x608/0x920 [ath12k] ieee80211_process_measurement_req+0x320/0x348 [mac80211] ieee80211_tx_dequeue+0x9ac/0x1518 [mac80211] ieee80211_tx_dequeue+0xb14/0x1518 [mac80211] ieee80211_tx_prepare_skb+0x224/0x254 [mac80211] ieee80211_xmit+0xec/0x100 [mac80211] __ieee80211_subif_start_xmit+0xc50/0xf40 [mac80211] ieee80211_subif_start_xmit+0x2e8/0x308 [mac80211] netdev_start_xmit+0x150/0x18c dev_hard_start_xmit+0x74/0xc0 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: iommu/vt-d: Corrección de UAF en la desvinculación de sva con IOPF pendientes. El commit 17fce9d2336d ("iommu/vt-d: Colocar la habilitación de iopf en la ruta de conexión del dominio") deshabilita IOPF en el dispositivo eliminándolo de la cola de IOPF de su IOMMU cuando el último dominio con capacidad para IOPF se desvincula del dispositivo. Desafortunadamente, esto se realizó en un lugar incorrecto donde aún hay IOPF pendientes. Como resultado, se puede generar un error de use-after-free y, finalmente, un pánico del kernel con un seguimiento del kernel similar al siguiente: refcount_t: underflow; use-after-free. ADVERTENCIA: CPU: 3 PID: 313 en lib/refcount.c:28 refcount_warn_saturate+0xd8/0xe0 Cola de trabajo: iopf_queue/dmar0-iopfq iommu_sva_handle_iopf Rastreo de llamadas: iopf_free_group+0xe/0x20 process_one_work+0x197/0x3d0 worker_thread+0x23a/0x350 ? rescuer_thread+0x4a0/0x4a0 kthread+0xf8/0x230 ? finish_task_switch.isra.0+0x81/0x260 ? kthreads_online_cpu+0x110/0x110 ? kthreads_online_cpu+0x110/0x110 ret_from_fork+0x13b/0x170 ? kthreads_online_cpu+0x110/0x110 ret_from_fork_asm+0x11/0x20 ---[ end trace 0000000000000000 ]--- La función intel_pasid_tear_down_entry() se encarga de impedir que el hardware genere nuevos fallos de página y de eliminar todos los que se están ejecutando. Por lo tanto, mover iopf_for_domain_remove() después de esta función debería resolver este problema.