Vulnerabilidad en kernel de Linux (CVE-2024-27405)

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.