Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: s390/sclp: corrige la limpieza de sclp_init() en caso defallo. Si sclp_init()fallo, solo se limpia parcialmente: si hay varias llamadas fallidas a sclp_init(), sclp_state_change_event se agregará varias veces. a sclp_reg_list, lo que resulta en la siguiente advertencia: ------------[ cortar aquí ]------------ list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, siguiente=000003ffe1598c10. ADVERTENCIA: CPU: 0 PID: 1 en lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8 CPU: 0 PID: 1 Comm: swapper/0 No contaminado 6.10.0-rc3 Krnl PSW: 0404c00180000000 000003ffe0d6076a (__list_ad d_valid_or_report+0xe2/0xf8 ) R:0 T:1 IO:0 EX:0 Clave:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 ... Seguimiento de llamadas: [<000003ffe0d6076a> ] __list_add_valid_or_report+0xe2/0xf8 ([<000003ffe0d60766>] __list_add_valid_or_report+0xde/0xf8) [<000003ffe0a8d37e>] sclp_init+0x40e/0x450 [<000003ffe00009f2>] _one_initcall+0x42/0x1e0 [<000003ffe15b77a6>] do_initcalls+0x126/0x150 [< 000003ffe15b7a0a>] kernel_init_freeable+0x1ba/0x1f8 [<000003ffe0d6650e>] kernel_init+0x2e/0x180 [<000003ffe000301c>] __ret_from_fork+0x3c/0x60 [<000003ffe0d759ca>] _from_fork+0xa/0x30 Solucionar esto eliminando sclp_state_change_event de sclp_reg_list cuando falla sclp_init() .

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: evitar cálculos de direcciones mediante indexación de matriz fuera de los límites. Se debe configurar req->n_channels antes de poder usar req->channels[]. Este parche soluciona uno de los problemas encontrados en [1]. [83.964255] UBSAN: índice de matriz fuera de los límites en net/mac80211/scan.c:364:4 [83.964258] el índice 0 está fuera de rango para el tipo 'struct ieee80211_channel *[]' [...] [ 83.964264] Seguimiento de llamadas: [ 83.964267] [ 83.964269] dump_stack_lvl+0x3f/0xc0 [ 83.964274] __ubsan_handle_out_of_bounds+0xec/0x110 [ 83.964278] escaneo+0x2db/0x4b0 [ 83.964281] __ieee80211_start_scan+0x601/0x990 [ 83.964291] nl80211_trigger_scan+0x874/ 0x980 [83.964295] genl_family_rcv_msg_doit+0xe8/0x160 [83.964298] genl_rcv_msg+0x240/0x270 [...] [1] https://bugzilla.kernel.org/show_bug.cgi?id=218810

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: wext: agregue verificación de datos SIOCSIWSCAN adicional En 'cfg80211_wext_siwscan()', agregue verificación adicional si el número de canales pasados a través de 'ioctl(sock, SIOCSIWSCAN, ...) ' no excede IW_MAX_FREQUENCIES y rechaza la solicitud no válida con -EINVAL en caso contrario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/radeon: verifique que bo_va->bo no sea NULL antes de usarlo. La llamada a radeon_vm_clear_freed podría borrar bo_va->bo, por lo que debemos verificarlo antes de eliminar la referencia.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: bluetooth/l2cap: sync sock recv cb and release El problema ocurre entre la llamada al sistema para cerrar el calcetín y hci_rx_work, donde el primero libera el calcetín y el segundo accede a él sin protección de bloqueo. . CPU0 CPU1 ---- ---- sock_close hci_rx_work l2cap_sock_release hci_acldata_packet l2cap_sock_kill l2cap_recv_frame sk_free l2cap_conless_channel l2cap_sock_recv_cb Si hci_rx_work procesa los datos que deben recibirse antes de cerrar el sock, entonces todo es normal; De lo contrario, el hilo de trabajo puede acceder al sock liberado al recibir datos. Agregue un mutex chan en la devolución de llamada rx del sock para lograr la sincronización entre la liberación del sock y recv cb. Sock está muerto, así que configure los datos de chan en NULL, evite que otros usen un puntero de sock no válido.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: powerpc/eeh: evita un posible bloqueo cuando cambia edev->pdev Si se elimina un dispositivo PCI durante eeh_pe_report_edev(), edev->pdev cambiará y puede causar un bloqueo, mantenga presionado el botón PCI vuelve a escanear/quitar bloqueo mientras se toma una copia de edev->pdev->bus.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ibmvnic: agregue verificación de tx para evitar fugas de skb A continuación se muestra un resumen de cómo el controlador almacena una referencia a un skb durante la transmisión: tx_buff[free_map[consumer_index]]->skb = new_skb ; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index++; Donde los datos variables se ven así: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] consumer_index^ tx_buff == [skb=null, skb=, skb=, skb=null, skb=null ] El controlador tiene comprobaciones para garantizar que free_map[consumer_index] apunte a un índice válido, pero no hubo ninguna verificación para garantizar que este índice apunte a una dirección skb nula o no utilizada. Entonces, si, por casualidad, nuestras listas free_map y tx_buff no están sincronizadas, entonces estábamos arriesgándonos a una pérdida de memoria skb. Esto podría provocar que el control de congestión de TCP deje de enviar paquetes, lo que eventualmente provocaría ETIMEDOUT. Por lo tanto, agregue un condicional para garantizar que la dirección skb sea nula. De lo contrario, advierta al usuario (porque todavía es un error que debe corregirse) y libere el puntero antiguo para evitar problemas de memleak/tcp.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ASoC: topología: corrige referencias a la memoria liberada. La mayoría de los usuarios, después de analizar un archivo de topología, liberan la memoria utilizada por este, por lo que tener referencias de puntero directamente al contenido del archivo de topología es incorrecto. Utilice devm_kmemdup() para asignar memoria según sea necesario.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: PPC: Book3S HV: Prevenir UAF en kvm_spapr_tce_attach_iommu_group() Al informó un posible use after free (UAF) en kvm_spapr_tce_attach_iommu_group(). Busca `stt` en tablefd, pero luego continúa usándolo después de realizar fdput() en el fd devuelto. Después de fdput(), otro hilo puede cerrar el tablefd. El cierre llama a kvm_spapr_tce_release() y luego a release_spapr_tce_table() (a través de call_rcu()) que libera `stt`. Aunque hay llamadas a rcu_read_lock() en kvm_spapr_tce_attach_iommu_group(), no son suficientes para evitar la UAF, porque `stt` se usa fuera de las regiones bloqueadas. Con un retraso artificial después de fdput() y un programa de espacio de usuario que desencadena la ejecución, KASAN detecta la UAF: ERROR: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] Lectura de tamaño 4 en dirección c000200027552c30 por tarea kvm-vfio/2505 CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1 Nombre de hardware: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35 -g1851b2a06 Seguimiento de llamadas de PowerNV: dump_stack_lvl+0xb4/0x108 (no confiable) print_report+0x2b4/0x6ec kasan_report+0x118/0x2b0 __asan_load4+0xb8/0xd0 kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] kvm_vfio_set_attr+0x524/0xac0 [kvm] kvm_device_ioctl+0x144/0x240 [kvm] sys_ioctl+0x62c/0x1810 system_call_exception+0x190/0x440 system_call_vectored_common+0x15c/0x2ec ... Liberado por la tarea 0: ... kfree+0xec/0x3e0 release_spapr_tce_table+0xd4/0x11c [rcu_core+0x568/0 x16a0 handle_softirqs+0x23c /0x920 do_softirq_own_stack+0x6c/0x90 do_softirq_own_stack+0x58/0x90 __irq_exit_rcu+0x218/0x2d0 irq_exit+0x30/0x80 arch_local_irq_restore+0x128/0x230 arch_local_irq_enable+0x1c/0x 30 cpuidle_enter_state+0x134/0x5cc cpuidle_enter+0x6c/0xb0 call_cpuidle+0x7c/0x100 do_idle+0x394 /0x410 cpu_startup_entry+0x60/0x70 start_secondary+0x3fc/0x410 start_secondary_prolog+0x10/0x14 Solucionarlo retrasando fdput() hasta que `stt` ya no esté en uso, que es efectivamente toda la función. Para mantener el parche mínimo, agregue una llamada a fdput() en cada una de las rutas de retorno existentes. El trabajo futuro puede convertir la función a limpieza de estilo goto o __cleanup. Con la solución implementada, el caso de prueba ya no activa la UAF.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i40e: corrige la descarga del programa XDP mientras se elimina el controlador La confirmación 6533e558c650 ("i40e: corrige la ruta de reinicio mientras se elimina el controlador") introdujo un nuevo estado de PF "__I40E_IN_REMOVE" para bloquear la modificación del programa XDP mientras se elimina el controlador. Desafortunadamente, tal cambio es útil sólo si la devolución de llamada ".ndo_bpf()" fue llamada fuera del contexto rmmod porque descargar el programa XDP existente también es parte del procedimiento de eliminación del controlador. En otras palabras, desde el contexto rmmod se espera que el controlador descargue el programa XDP sin informar ningún error. De lo contrario, la advertencia del kernel con la pila de llamadas se imprime en dmesg. Ejemplo de escenario de error: 1. Cargue el controlador i40e. 2. Cargue el programa XDP. 3. Descargue el controlador i40e (usando el comando "rmmod"). El registro de advertencia del kernel de ejemplo: [ +0.004646] ADVERTENCIA: CPU: 94 PID: 10395 en net/core/dev.c:9290 unregister_netdevice_many_notify+0x7a9/0x870 [...] [ +0.010959] RIP: 0010:unregister_netdevice_many_notify+0x7a9/ 0x870 [...] [ +0.002726] Seguimiento de llamadas: [ +0.002457] [ +0.002119] ? __advertir+0x80/0x120 [ +0.003245] ? unregister_netdevice_many_notify+0x7a9/0x870 [+0.005586]? report_bug+0x164/0x190 [+0.003678] ? handle_bug+0x3c/0x80 [+0.003503]? exc_invalid_op+0x17/0x70 [+0.003846]? asm_exc_invalid_op+0x1a/0x20 [+0.004200]? unregister_netdevice_many_notify+0x7a9/0x870 [+0.005579]? unregister_netdevice_many_notify+0x3cc/0x870 [ +0.005586] unregister_netdevice_queue+0xf7/0x140 [ +0.004806] unregister_netdev+0x1c/0x30 [ +0.003933] i40e_vsi_release+0x87/0x2f0 [i40e] [ + 0.004604] i40e_remove+0x1a1/0x420 [i40e] [ +0.004220 ] pci_device_remove+0x3f/0xb0 [ +0.003943] device_release_driver_internal+0x19f/0x200 [ +0.005243] driver_detach+0x48/0x90 [ +0.003586] bus_remove_driver+0x6d/0xf0 [ +0.003939] ister_driver+0x2e/0xb0 [ +0.004278] i40e_exit_module+0x10/ 0x5f0 [i40e] [ +0.004570] __do_sys_delete_module.isra.0+0x197/0x310 [ +0.005153] do_syscall_64+0x85/0x170 [ +0.003684] ? syscall_exit_to_user_mode+0x69/0x220 [+0.004886]? do_syscall_64+0x95/0x170 [ +0.003851] ? exc_page_fault+0x7e/0x180 [ +0.003932] Entry_SYSCALL_64_after_hwframe+0x71/0x79 [ +0.005064] RIP: 0033:0x7f59dc9347cb [ +0.003648] Código: 73 01 c3 48 8b 0d 65 16 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 16 0c 00 f7 d8 64 89 01 48 [ +0. 018753] RSP : 002b:00007ffffac99048 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ +0.007577] RAX: ffffffffffffffda RBX: 0000559b9bb2f6e0 RCX: 00007f59dc9347cb [ +0. 007140] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000559b9bb2f748 [ +0.007146] RBP: 00007ffffac99070 R08: 1999999999999999 R09: 0000000000000 [ +0.007133] R10: 00007f59dc9a5ac0 R11: 0000000000000206 R12: 0000000000000000 [ +0.007141] R13: 00007ffffac992d8 R14: 0000559b9bb2f6e0 5: 0000000000000000 [+0.007151] [+0.002204] ---[ final de seguimiento 0000000000000000 ]--- Solucionar esto comprobando si el programa XDP se está cargando o descargando. Luego, bloquee solo la carga de un nuevo programa mientras "__I40E_IN_REMOVE" esté configurado. Además, mueva el indicador de prueba "__I40E_IN_REMOVE" al comienzo de la devolución de llamada XDP_SETUP para evitar operaciones y comprobaciones innecesarias.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: archivos de caché: asignación cíclica de msg_id para evitar la reutilización La reutilización de msg_id después de una solicitud de reapertura completada maliciosamente puede causar que una solicitud de lectura permanezca sin procesar y resulte en un bloqueo, como se muestra a continuación: t1 | t2 | t3 ------------------------------------------------- cachefiles_ondemand_select_req cachefiles_ondemand_object_is_close(A) cachefiles_ondemand_set_object_reopening(A) queue_work(fscache_object_wq, &info->work) ondemand_object_worker cachefiles_ondemand_init_object(A) cachefiles_ondemand_send_req(OPEN) // obtener msg_id 6 _completion(&req_A->done) cachefiles_ondemand_daemon_read // leer msg_id 6 req_A cachefiles_ondemand_get_fd copy_to_user // Finalización maliciosa msg_id 6 copen 6,-1 cachefiles_ondemand_copen complete(&req_A->done) // no configurará el objeto para que se cierre // porque ondemand_id && fd es válido. // ondemand_object_worker() está listo // pero el objeto aún se está reabriendo. // new open req_B cachefiles_ondemand_init_object(B) cachefiles_ondemand_send_req(OPEN) // reutilizar msg_id 6 process_open_req copen 6,A.size // El copen fallido esperado se ejecutó con éxito Se espera que copen falle y, cuando lo hace, cierra fd, lo que establece el objeto se cierra y luego el cierre activa nuevamente. Sin embargo, debido a que la reutilización de msg_id da como resultado un copen exitoso, el fd anónimo no se cierra hasta que el demonio sale. Por lo tanto, las solicitudes de lectura que esperan que se complete la reapertura pueden desencadenar una tarea colgada. Para evitar este problema, asigne msg_id cíclicamente para evitar reutilizar msg_id durante un período de tiempo muy corto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vfio/pci: inicia la variable de conteo al recopilar dispositivos de reinicio en caliente. La variable de conteo se usa sin inicialización, genera errores en el conteo de dispositivos y bloquea el espacio de usuario si se calienta. Se activa el restablecimiento de la ruta de información.