Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tipc: protección contra el desbordamiento de búfer de cadena Smatch informa que copiar media_name e if_name a name_parts puede sobrescribir el destino. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' demasiado grande para 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' demasiado grande para 'name_parts->if_name' (1010102 vs 16) Este parece ser el caso, así que protéjase contra esta posibilidad usando strscpy() y fallando si ocurre un truncamiento. Introducido por el commit b97bf3fd8f6a ("[TIPC] Fusión inicial") Compilación probada únicamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cifs: Se corrige el desbordamiento de búfer al analizar los puntos de análisis de NFS ReparseDataLength es la suma del tamaño de InodeType y el tamaño de DataBuffer. Por lo tanto, para obtener el tamaño de DataBuffer, es necesario restar el tamaño de InodeType de ReparseDataLength. La función cifs_strndup_from_utf16() está accediendo actualmente a buf->DataBuffer en la posición después del final del búfer porque no resta el tamaño de InodeType de la longitud. Solucione este problema y reste correctamente la variable len. El miembro InodeType solo está presente cuando el búfer de análisis es lo suficientemente grande. Verifique ReparseDataLength antes de acceder a InodeType para evitar otro acceso no válido a la memoria. Los valores rdev principales y secundarios también están presentes solo cuando el búfer de análisis es lo suficientemente grande. Verifique el tamaño del búfer de análisis antes de llamar a reparse_mkdev().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: lantiq_etop: fix memory breach Al aplicar relleno, el búfer no se pone a cero, lo que da como resultado la divulgación de memoria. Los datos mencionados se observan en el cable. Este parche usa skb_put_padto() para rellenar los marcos Ethernet correctamente. La función mencionada pone a cero el búfer expandido. En caso de que el paquete no se pueda rellenar, se descarta silenciosamente. Las estadísticas tampoco se incrementan. Este controlador no admite estadísticas en el antiguo formato de 32 bits ni en el nuevo formato de 64 bits. Estos se agregarán en el futuro. En su forma actual, el parche debería poder retroportarse fácilmente a versiones estables. Las MAC de Ethernet en Amazon-SE y Danube no pueden realizar relleno de los paquetes en hardware, por lo que se debe aplicar relleno de software.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: dsa: mejorar la secuencia de apagado Alexander Sverdlin presenta 2 problemas durante el apagado con el controlador lan9303. Uno es específico de lan9303 y el otro simplemente se reproduce allí. El primer problema es que lan9303 es único entre los controladores DSA en el sentido de que llama a dev_get_drvdata() en un "tiempo de ejecución arbitrario" (no sondeo, no apagado, no eliminación): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() Pero nunca detenemos phy_state_machine(), por lo que puede continuar ejecutándose después de dsa_switch_shutdown(). Nuestro patrón común en todos los controladores DSA es establecer drvdata en NULL para suprimir el método remove() que puede venir después. Pero en este caso resultará en un NPD. El segundo problema es que la forma en que establecemos dp->conduit->dsa_ptr = NULL; es concurrente con el procesamiento de paquetes de recepción. dsa_switch_rcv() verifica una vez si dev->dsa_ptr es NULL, pero después, en lugar de continuar usando ese valor no NULL, dev->dsa_ptr se desreferencia una y otra vez sin verificaciones NULL: dsa_conduit_find_user() y muchos otros lugares. Entre desreferencias, no hay bloqueo para asegurar que lo que era válido una vez continúa siendo válido. Ambos problemas tienen el aspecto común de que cerrar la interfaz del conducto los resuelve. En el primer caso, dev_close(conduit) activa el evento NETDEV_GOING_DOWN en dsa_user_netdevice_event() que también cierra los puertos de usuario. dsa_port_disable_rt() llama a phylink_stop(), que detiene sincrónicamente la máquina de estado de phylink, y ds->ops->phy_read() ya no llamará al controlador después de este punto. En el segundo caso, dev_close(conduit) debería hacer esto, según Documentation/networking/driver.rst: | Quiescence | ---------- | | Después de que se haya llamado a la rutina ndo_stop, el hardware no debe recibir ni transmitir ningún dato. Todos los paquetes en tránsito deben ser abortados. Si es necesario, sondee o espere a que se completen los comandos de reinicio. Por lo tanto, debería ser suficiente para garantizar que más adelante, cuando pongamos a cero conduit->dsa_ptr, no habrá ninguna llamada dsa_switch_rcv() concurrente en este conducto. La adición de la función netif_device_detach() es para garantizar que las solicitudes ioctls, rtnetlinks y ethtool en los puertos de usuario ya no se propaguen al controlador; ya no estamos preparados para manejarlas. La condición de ejecución en realidad no existía cuando el commit 0650bf52b31f ("net: dsa: sea compatible con los maestros que cancelan el registro al apagar") introdujo por primera vez dsa_switch_shutdown(). Se creó más tarde, cuando dejamos de cancelar el registro de las interfaces de usuario desde un lugar incorrecto y simplemente reemplazamos esa secuencia con una puesta a cero de ejecución de conduit->dsa_ptr (que no garantiza que las interfaces no estén activas).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: afs: Arreglar la configuración del indicador de respuesta del servidor En afs_wait_for_operation(), configuramos la transcripción del indicador de respuesta de llamada en el registro del servidor que usamos después de realizar el bucle de iteración del servidor de archivos, pero es posible salir del bucle después de haber recibido una respuesta del servidor que descartamos (por ejemplo, devolvió un aborto o comenzamos a recibir datos, pero la llamada no se completó). Esto significa que op->server podría ser NULL, pero no lo verificamos antes de intentar configurar el indicador del servidor.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: eliminar ppath de ext4_ext_replay_update_ex() para evitar una doble liberación Al llamar a ext4_force_split_extent_at() en ext4_ext_replay_update_ex(), se actualiza 'ppath' pero es 'path' el que se libera, lo que potencialmente desencadena una doble liberación en el siguiente proceso: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path Primero liberado *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! Por lo tanto, elimine el ppath innecesario y use path directamente para evitar este problema. Y use ext4_find_extent() directamente para actualizar path, evitando la asignación y liberación de memoria innecesaria. Además, propague el error devuelto por ext4_find_extent() en lugar de usar códigos de error extraños.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/v3d: Evitar el acceso fuera de los límites en las extensiones de consulta de rendimiento. Compruebe que la cantidad de espacio de usuario de perfmons que pasa en las extensiones de copia y restablecimiento no sea mayor que el almacenamiento interno del kernel donde se copiarán los identificadores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: i2c: stm32f7: No preparar/despreparar el reloj durante la suspensión/reanudación en tiempo de ejecución En caso de que haya algún tipo de controlador de reloj conectado a este controlador de bus I2C, por ejemplo Versaclock o incluso un códec I2C AIC32x4, entonces una transferencia I2C activada desde la devolución de llamada clk_ops .prepare del controlador de reloj puede activar un bloqueo en el mutex prepare_lock de drivers/clk/clk.c. Esto se debe a que el controlador de reloj primero toma el mutex prepare_lock y luego realiza la operación de preparación, incluido su acceso I2C. El acceso I2C reanuda este controlador de bus I2C a través de la devolución de llamada .runtime_resume, que llama a clk_prepare_enable(), que intenta tomar el mutex prepare_lock nuevamente y se bloquea. Dado que el reloj ya está preparado desde probe() y no preparado en remove(), use llamadas clk_enable()/clk_disable() simples para habilitar y deshabilitar el reloj en la suspensión y reanudación del tiempo de ejecución, para evitar alcanzar el mutex prepare_lock.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Aumentar el tamaño de la matriz de dummy_boolean [POR QUÉ] dml2_core_shared_mode_support y dml_core_mode_support acceden al tercer elemento de dummy_boolean, es decir, hw_debug5 = &s->dummy_boolean[2], cuando dummy_boolean tiene un tamaño de 2. Cualquier asignación a hw_debug5 provoca un OVERRUN. [CÓMO] Aumentar el tamaño de la matriz de dummy_boolean a 3. Esto corrige 2 problemas de OVERRUN informados por Coverity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Desasignar memoria DML si falla la asignación [Por qué] Cuando falla la asignación de memoria DML al crear un estado de DC, la memoria no se desasigna posteriormente, lo que da como resultado una estructura no inicializada que no es NULL. [Cómo] Desasignar memoria si falla la asignación de memoria DML.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: r8169: se agregaron campos del contador de recuento con RTL8125. RTL8125 agregó campos al contador de recuento, lo que puede provocar que el chip desactive estos nuevos campos en la memoria no asignada. Por lo tanto, asegúrese de que el área de memoria asignada sea lo suficientemente grande como para contener todos los valores del contador de recuento, incluso si solo usamos partes de ella.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: NFSD: Limitar el número de operaciones de COPIA asíncronas concurrentes No parece que nada limite el número de operaciones de COPIA asíncronas concurrentes que los clientes pueden iniciar. Además, según tengo entendido, cada COPIA asíncrona puede copiar una cantidad ilimitada de fragmentos de 4 MB, por lo que puede ejecutarse durante mucho tiempo. Por lo tanto, en mi opinión, la COPIA asíncrona puede convertirse en un vector de denegación de servicio (DoS). Agregue un mecanismo de restricción que limite el número de operaciones de COPIA en segundo plano concurrentes. Comience de manera simple e intente ser justo: este parche implementa un límite por espacio de nombres. Una solicitud de COPIA asíncrona que se produce mientras se excede este límite obtiene NFS4ERR_DELAY. El cliente solicitante puede elegir enviar la solicitud nuevamente después de un retraso o volver a una copia de estilo de lectura/escritura tradicional. Si es necesario hacer que el mecanismo sea más sofisticado, podemos tratarlo en parches futuros.