Vulnerabilidades

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: libertas: arreglados algunas memleaks en lbs_allocate_cmd_buffer() En la declaración for de lbs_allocate_cmd_buffer(), si falló la asignación de cmdarray[i].cmdbuf, tanto cmdarray como cmdarray[i] Es necesario liberar ].cmdbuf. De lo contrario, habrá fugas de memoria en lbs_allocate_cmd_buffer().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: ncm: corregido el manejo de paquetes de longitud de bloque cero Al conectarnos a un host Linux con CDC_NCM_NTB_DEF_SIZE_TX configurado en 65536, se ha observado que recibimos paquetes cortos, que vienen en intervalo de 5 a 10 segundos a veces y tiene una longitud de bloque cero, pero aún contiene 1 o 2 datagramas válidos presentes. Según la especificación NCM: "Si wBlockLength = 0x0000, el bloque finaliza con un paquete corto. En este caso, la transferencia USB aún debe ser más corta que dwNtbInMaxSize o dwNtbOutMaxSize. Si se envían exactamente bytes dwNtbInMaxSize o dwNtbOutMaxSize, y el tamaño es un múltiplo de wMaxPacketSize para la pipe dada, entonces no se enviará ningún ZLP. wBlockLength= 0x0000 debe usarse con extremo cuidado, debido a la posibilidad de que el host y el dispositivo no estén sincronizados y debido a problemas de prueba con wBlockLength = 0x0000. permite al remitente reducir la latencia comenzando a enviar un NTB muy grande y luego acortándolo cuando el remitente descubre que no hay datos suficientes para justificar el envío de un NTB grande". Sin embargo, existe un problema potencial con la implementación actual, ya que verifica para la aparición de múltiples NTB en una sola devolución verificando si los bytes sobrantes a procesar son cero o no. Si la longitud del bloque es cero, procesaríamos el mismo NTB infinitamente porque los bytes sobrantes nunca son cero y provocan un bloqueo. Solucione este problema rescatando si la longitud del bloque es cero.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: io_uring: corrige io_queue_proc modificando req->flags Con múltiples entradas de encuesta, __io_queue_proc() podría estar ejecutándose en paralelo con los manejadores de encuestas y posiblemente con task_work, no deberíamos modificar req->flags descuidadamente. allá. io_poll_double_prepare() maneja un caso similar con bloqueo pero es mucho más fácil moverlo a __io_arm_poll_handler().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: vt: corregida la corrupción del búfer Unicode al eliminar caracteres. Este es el mismo problema que se solucionó para el búfer de texto VGA en la confirmación 39cdb68c64d8 ("vt: corrige la superposición de memoria al eliminar caracteres en el búfer "). La solución también es la misma, es decir, reemplazar memcpy() con memmove() debido a la superposición de buffers.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ubifs: establece la actualización de la página en el lugar correcto. Las lecturas de la caché de la página no tienen bloqueo, por lo que configurar la actualización de la página recién asignada antes de que la sobrescribamos con los datos que se supone que debe contener lo hará. permitir que un lector simultáneo vea datos antiguos. Mueva la llamada a SetPageUptodate a ubifs_write_end(), que es después de que copiamos los nuevos datos en la página.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: udc: elimina la advertencia cuando la cola está deshabilitada ep Es posible que se active el siguiente mensaje de advertencia desde la función de almacenamiento masivo, ADVERTENCIA: CPU: 6 PID: 3839 en drivers/usb/gadget/udc /core.c:294 usb_ep_queue+0x7c/0x104 pc: usb_ep_queue+0x7c/0x104 lr: fsg_main_thread+0x494/0x1b3c La causa principal es que la función de almacenamiento masivo intenta poner en cola la solicitud desde el hilo principal, pero es posible que otro hilo ya deshabilite ep cuando la función se deshabilita. Como no hay ningún fallo de función en el controlador, para evitar el esfuerzo de corregir la advertencia, cambie WARN_ON_ONCE() en usb_ep_queue() a pr_debug().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: firewire: ohci: evita la fuga de IRQ sobrante al desvincular confirmación5a95f1ded28691e6 ("firewire: ohci: usa devres para IRQ solicitada") también eliminó la llamada a free_irq() en pci_remove (), lo que lleva a un irq sobrante de devm_request_irq() en pci_disable_msi() en pci_remove() al desvincular el controlador del dispositivo remove_proc_entry: eliminando el directorio no vacío 'irq/136', filtrando al menos 'firewire_ohci' Call Trace:? remove_proc_entry+0x19c/0x1c0? __advertir+0x81/0x130 ? remove_proc_entry+0x19c/0x1c0? report_bug+0x171/0x1a0? console_unlock+0x78/0x120? handle_bug+0x3c/0x80? exc_invalid_op+0x17/0x70? asm_exc_invalid_op+0x1a/0x20? remove_proc_entry+0x19c/0x1c0 unregister_irq_proc+0xf4/0x120 free_desc+0x3d/0xe0? kfree+0x29f/0x2f0 irq_free_descs+0x47/0x70 msi_domain_free_locked.part.0+0x19d/0x1d0 msi_domain_free_irqs_all_locked+0x81/0xc0 pci_free_msi_irqs+0x12/0x40 pci_disable_msi+0x4c/0x60 pci_remove+0x9d/0xc0 [firewire_ohci 01b483699bebf9cb07a3d69df0aa2bee71db1b26] pci_device_remove+0x37/0xa0 dispositivo_release_driver_internal+ 0x19f/0x200 unbind_store+0xa1/0xb0 elimina irq con devm_free_irq() antes de pci_disable_msi() también elimínalo en fail_msi: de pci_probe() ya que esto conduciría a una fuga idéntica

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu: amdgpu_ttm_gart_bind establece el indicador vinculado a gtt. De lo contrario, después de que se libera GTT bo, se libera el espacio GTT y gart, pero amdgpu_ttm_backend_unbind no borrará la entrada de la tabla de páginas de gart y dejará una asignación válida. entrada que apunta a la página del sistema obsoleto. Luego, si la GPU accede a la dirección de Gart por error, leerá un valor indefinido en lugar de un error de página, lo que será más difícil de depurar y reproducir el problema real.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: LoongArch: define el gancho __io_aw() como mmiowb(). Confirmación fb24ea52f78e0d595852e ("drivers: elimina las invocaciones explícitas de mmiowb()") elimina todos los mmiowb() en los controladores, pero dice : "NOTA: mmiowb() solo ha garantizado el pedido junto con spin_unlock(). Sin embargo, emparejar cada eliminación de mmiowb() en este parche con la llamada correspondiente a spin_unlock() no es nada trivial, por lo que existe una pequeña posibilidad que este cambio puede hacer retroceder cualquier controlador que dependa incorrectamente de mmiowb() para ordenar escrituras MMIO entre CPU usando sincronización sin bloqueo". El mmio en radeon_ring_commit() está protegido por un mutex en lugar de un spinlock, pero en el mutex fastpath se comporta de manera similar al spinlock. Podemos agregar llamadas mmiowb() en el controlador radeon, pero el mantenedor dice que no le gusta esa solución, y radeon no es el único ejemplo de mmio protegido por mutex. Entonces deberíamos extender el sistema de seguimiento mmiowb de spinlock a mutex, y tal vez a otras primitivas de bloqueo. Esto no es fácil y propenso a errores, por lo que lo solucionamos en el código arquitectónico, simplemente definiendo el gancho __io_aw() como mmiowb(). Y ya no necesitamos anular queued_spin_unlock() así que use la definición genérica. Sin esto, obtenemos este error cuando ejecutamos 'glxgears' en arquitecturas de ordenamiento débiles como LoongArch: radeon 0000:04:00.0: el anillo 0 se detuvo durante más de 10324 mseg radeon 0000:04:00.0: el anillo 3 se detuvo durante más de 10240 mseg radeon 0000:04:00.0: bloqueo de GPU (ID de valla actual 0x000000000001f412 ID de última valla 0x000000000001f414 en el anillo 3) radeon 0000:04:00.0: Bloqueo de GPU (ID de valla actual 0x000000000000f940 ID de última valla 0x000 000000000f941 en el anillo 0) radeon 0000:04:00.0: la programación IB falló (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* No se pudo actualizar BO_VA (-35) radeon 0000:04:00.0: falló la programación de IB (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* No se pudo actualizar BO_VA (-35) radeon 0000:04:00.0: falló la programación de IB (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* No se pudo actualizar BO_VA (-35) radeon 0000:04:00.0: falló la programación de IB (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* No se pudo actualizar BO_VA (-35) radeon 0000:04:00.0: falló la programación de IB (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* No se pudo actualizar BO_VA (-35) radeon 0000:04:00.0: falló la programación de IB (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* No se pudo actualizar BO_VA (-35) radeon 0000:04:00.0: falló la programación de IB (-35). [drm:radeon_gem_va_ioctl [radeon]] *ERROR* No se pudo actualizar BO_VA (-35)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fs/aio: verifique IOCB_AIO_RW antes de la conversión de struct aio_kiocb. El primer argumento kiocb_set_cancel_fn() puede apuntar a una estructura kiocb que no está incrustada dentro de struct aio_kiocb. Con el código actual, dependiendo del compilador, la lectura req->ki_ctx ocurre antes de la prueba IOCB_AIO_RW o después de esa prueba. Mueva la lectura req->ki_ctx de modo que se garantice que la prueba IOCB_AIO_RW se realice primero.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: soc: fsl: qbman: use spinlock sin formato para cgr_lock smp_call_function siempre ejecuta su devolución de llamada en un contexto IRQ duro, incluso en PREEMPT_RT, donde los spinlocks pueden dormir. Por lo tanto, necesitamos usar un spinlock sin formato para cgr_lock para asegurarnos de que no estamos esperando una tarea inactiva. Aunque este error ha existido por un tiempo, no fue evidente hasta la confirmación ef2a8d5478b9 ("net: dpaa: Ajustar la profundidad de la cola al cambiar la velocidad") que invoca smp_call_function_single a través de qman_update_cgr_safe cada vez que un enlace sube o baja.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: brcmfmac: corregido el error de use after free en brcmf_cfg80211_detach Este es el parche candidato de CVE-2023-47233: https://nvd.nist.gov/vuln/detail /CVE-2023-47233 En el controlador brcm80211, comienza con la siguiente cadena de invocación para iniciar un trabajador de tiempo de espera: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg ->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); Si desconectamos el USB mediante hotplug, llamará a brcmf_usb_disconnect para realizar la limpieza. La cadena de invocación es: brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); Mientras que el activador de tiempo de espera aún puede estar ejecutándose. Esto provocará un error de use after free en cfg en brcmf_cfg80211_escan_timeout_worker. Soluciónelo eliminando el temporizador y cancelando el trabajador en brcmf_cfg80211_detach. [arend.vanspriel@broadcom.com: mantenga la eliminación del temporizador tal como está y cancele el trabajo justo antes de liberarlo]