Vulnerabilidades

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: Bluetooth: hci_core: cancelar todos los trabajos en hci_unregister_dev() syzbot informa que llamar a hci_release_dev() desde hci_error_reset() debido a hci_dev_put() desde hci_error_reset() puede causar un punto muerto en destroy_workqueue( ), porque hci_error_reset() se llama desde hdev->req_workqueue y destroy_workqueue() necesita vaciarse. Necesitamos asegurarnos de que hdev->{rx_work,cmd_work,tx_work} que están en cola en hdev->workqueue y hdev->{power_on,error_reset} que están en cola en hdev->req_workqueue ya no se estén ejecutando en el momento destroy_workqueue( hdev->cola de trabajo); destroy_workqueue(hdev->req_workqueue); se llaman desde hci_release_dev(). Llame a cancel_work_sync() en estos elementos de trabajo desde hci_unregister_dev() tan pronto como se elimine hdev->list de hci_dev_list.

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 ha resuelto la siguiente vulnerabilidad: powerpc/pseries: incluir en la lista blanca el objeto dtl slub para copiarlo en el espacio de usuario. La lectura del registro de seguimiento de envío desde /sys/kernel/debug/powerpc/dtl/cpu-* da como resultado un ERROR() cuando la configuración CONFIG_HARDENED_USERCOPY está habilitada como se muestra a continuación. ¡ERROR del kernel en mm/usercopy.c:102! Vaya: Excepción en modo kernel, sign: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Módulos vinculados en: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror _region_hash dm_log dm_mod fusible CPU: 27 PID: 1815 Comm: python3 No contaminado 6.10.0-rc3 #85 Nombre de hardware: IBM,9040-MRX POWER10 (sin procesar) 0x800200 0xf000006 de:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR : 00000000006ee6f8 REGS: c000000120c078c0 TRAP: 0700 No contaminado (6.10.0-rc3) MSR: 8000000000029033 CR: 2828220f XER: 0000000e CFAR: 00000001fdc80 MÁSCARA IRQ: 0 [ .. GPR omitidos... ] NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0 LR [c0000000005d23d0] usercopy_abort+0x74/0xb0 Seguimiento de llamadas: usercopy_abort+0x74/0xb0 (no confiable) __check_heap_object+0xf8/0x 120 check_heap_object+0x218/0x240 __check_object_size+0x84/ 0x1a4 dtl_file_read+0x17c/0x2c4 full_proxy_read+0x8c/0x110 vfs_read+0xdc/0x3a0 ksys_read+0x84/0x144 system_call_exception+0x124/0x330 system_call_vectored_common+0x15c/0x2ec --- interrupción: 3000 0x7fff81f3ab34 Confirmación 6d07d1cd300f ("copia de usuario: restringir cachés que no sean de copia de usuario) a tamaño 0") requiere que solo las áreas incluidas en la lista blanca en objetos de losa/slub se puedan copiar al espacio de usuario cuando el refuerzo de copia de usuario está habilitado usando CONFIG_HARDENED_USERCOPY. Dtl contiene eventos de envío del hipervisor que se espera que sean leídos por usuarios privilegiados. Por lo tanto, marque esto como seguro para el acceso de los usuarios. Especifique useroffset=0 y usersize=DISPATCH_LOG_BYTES para incluir todo el objeto en la lista blanca.

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: 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: 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 resolvió la siguiente vulnerabilidad: drm/amd/display: Corrección de índice de matriz fuera de los límites en dml2/FCLKChangeSupport [Por qué] Posible acceso fuera de los límites en dml2_calculate_rq_and_dlg_params() porque se usó el valor de out_lowest_state_idx como índice para la matriz FCLKChangeSupport puede ser mayor que 1. [Cómo] Actualmente, el núcleo dml2 especifica valores idénticos para todos los elementos FCLKChangeSupport. Utilice siempre el índice 0 en la condición para evitar el acceso fuera de los límites.

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.