CVE-2024-35825

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.