Vulnerabilidades

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: dmaengine: dw-edma: HDMA: Añadida lectura sincronizada antes de iniciar la transferencia DMA en la configuración remota. El elemento de la lista vinculada y el puntero no se almacenan en la misma memoria que el registro del controlador HDMA. Si el registro del timbre se activa antes de la escritura completa de la lista vinculada, se producirá un error de condición de ejecución. En la configuración remota, solo podemos usar una lectura en la memoria para asegurarnos de que se haya producido la escritura completa.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/nouveau: mantiene los buffers DMA necesarios para suspender/reanudar Nouveau desasigna algunos buffers después del inicio de GPU que son necesarios para que la suspensión/reanudación de GPU funcione correctamente. Probablemente esto no sea un problema tan grande en sistemas donde la NVGPU es la única GPU, pero en configuraciones de múltiples GPU conduce a una regresión en la que el módulo del kernel genera errores y provoca una congelación de la representación en todo el sistema. Esta confirmación soluciona esa regresión moviendo los dos buffers necesarios para suspender y reanudar para que se desasignen durante la descarga del controlador en lugar de después del inicio.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Se corrigió la verificación de desbordamiento en mi_enum_attr()

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: wifi: nl80211: rechazar cambio de tipo con cambio de ID de malla Actualmente es posible cambiar el ID de malla cuando la interfaz aún no está en modo malla, al mismo tiempo que se cambia a modo malla. Esto lleva a una sobrescritura de datos en la unión wdev->u para el tipo de interfaz que tiene actualmente, causando que cfg80211_change_iface() haga cosas incorrectas al cambiar. Probablemente podríamos permitir configurar una interfaz para malla mientras configuramos la ID de malla al mismo tiempo haciendo un orden diferente de operaciones aquí, pero en realidad no hay ningún espacio de usuario que vaya a hacer esto, así que simplemente no permita cambios en iftype al configurar la ID de malla.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nft_flow_offload: restablece dst en el objeto de ruta después de configurar el flujo dst se transfiere al objeto de flujo, el objeto de ruta ya no es propietario. Restablezca el dst en el objeto de ruta; de lo contrario, si flow_offload_add() fallo, la ruta de error libera el dst dos veces, lo que provoca un desbordamiento insuficiente del recuento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mptcp: corrige carreras de datos en remote_id Similar al parche anterior, aborda la carrera de datos en remote_id, agregando las anotaciones ONCE adecuadas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: ncm: Evite soltar datagramas de NTB analizados correctamente. A veces se observa cuando se usa tethering a través de NCM con Windows 11 como host, en algunos casos, gadget_giveback tiene un byte. adjunta al final de una NTB adecuada. Cuando se analiza el NTB, la llamada de desenvolvimiento busca los bytes sobrantes en el SKB proporcionado por u_ether y, si hay bytes pendientes, los trata como un NTB separado y lo analiza. Pero en caso de que el segundo NTB (según la llamada de desenvolvimiento) esté defectuoso/dañado, todos los datagramas que se analizaron correctamente en el primer NTB y se guardaron en rx_list se descartan. Agregar algunos seguimientos personalizados mostró lo siguiente: [002] d..1 7828.532866: dwc3_gadget_giveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: K: ncm_unwrap_ntb para procesar: 1025 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67 [002] 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10 [002] d..1 7828.532869: ncm_unwrap_ntb: K: NTB analizado con 1 fotograma En este caso, la devolución es de 1025 bytes la longitud del bloque es 1024. El 1 byte restante (que es 0x00) no se analizará, lo que provocará la eliminación de todos los datagramas en rx_list. Lo mismo ocurre con los paquetes de tamaño 2048: [002] d..1 7828.557948: dwc3_gadget_giveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949 ncm_unwrap_ ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800 Lecroy muestra un byte adicional entrante confirmando que el byte proviene de la PC: Transferencia 2959 - Bytes transferidos (1025) Marca de tiempo ((18.524 843 590) - Transacción 8391 - Datos (1025 bytes) Marca de tiempo (18.524 843 590) --- Paquete 4063861 Datos (1024 bytes) Duración (2.117us) Inactivo (14.700 ns) Marca de tiempo (18.524 843 590) --- Paquete 4063863 Datos (1 byte) Duración (66.160 ns) Hora (282.000 ns) Marca de tiempo (18.524 845 722) Según el controlador de Windows, no se necesita ZLP si wBlockLength es distinto de cero, porque wBlockLength distinto de cero ya le ha dicho al lado de la función el tamaño de la transferencia. Sin embargo, hay dispositivos NCM en el mercado que dependen de ZLP siempre que wBlockLength sea múltiplo de wMaxPacketSize. Para manejar dichos dispositivos, se agrega un 0 adicional al final para que la transferencia ya no sea múltiplo de wMaxPacketSize.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: lib/Kconfig.debug: TEST_IOV_ITER depende de MMU Intentar ejecutar la prueba unitaria iov_iter en un sistema nommu como la emulación qemu kc705-nommu produce un bloqueo. KTAP versión 1 # Subprueba: iov_iter # módulo: kunit_iov_iter 1..9 BUG: fallo en mm/nommu.c:318/vmap()! Pánico del kernel: no se sincroniza: ¡BUG! La prueba llama a vmap() directamente, pero vmap() no es compatible con los sistemas nommu, lo que provoca el bloqueo. Por lo tanto, TEST_IOV_ITER debe depender de MMU.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Revertir "drm/amd/pm: resolve reboot exception for si oland" Esto revierte la confirmación e490d60a2f76bff636c68ce4fe34c1b6c34bbd86. Esto provoca bloqueos en SI cuando DC está habilitado y errores en los ciclos de reinicio y apagado del controlador.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: phonet/pep: corrige el uso picante de skb_queue_empty() Las colas de recepción están protegidas por sus respectivos spin-lock, no por el socket lock. Esto podría provocar que skb_peek() devuelva inesperadamente NULL o un puntero a un búfer de socket ya retirado de la cola.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Revertir "net/mlx5: Block entering switchdev mode with ns inconsistency" Esto revierte la confirmación 662404b24a4c4d839839ed25e3097571f5938b9b. La reversión es necesaria debido a la sospecha de que no sirve para nada y provoca un bloqueo.

Vulnerabilidad de autorización faltante en Flothemes Flo Forms. Este problema afecta a Flo Forms: desde n/a hasta 1.0.42.