// For flags

CVE-2024-27405

usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs

Severity Score

7.5
*CVSS v3.1

Exploit Likelihood

*EPSS

Affected Versions

*CPE

Public Exploits

0
*Multiple Sources

Exploited in Wild

-
*KEV

Decision

Track*
*SSVC
Descriptions

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs

It is observed sometimes when tethering is used over NCM with Windows 11
as host, at some instances, the gadget_giveback has one byte appended at
the end of a proper NTB. When the NTB is parsed, unwrap call looks for
any leftover bytes in SKB provided by u_ether and if there are any pending
bytes, it treats them as a separate NTB and parses it. But in case the
second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that
were parsed properly in the first NTB and saved in rx_list are dropped.

Adding a few custom traces showed the following:
[002] d..1 7828.532866: dwc3_gadget_giveback: ep1out:
req 000000003868811a length 1025/16384 zsI ==> 0
[002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 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] d..1 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: Parsed NTB with 1 frames

In this case, the giveback is of 1025 bytes and block length is 1024.
The rest 1 byte (which is 0x00) won't be parsed resulting in drop of
all datagrams in rx_list.

Same is case with packets of size 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 shows one byte coming in extra confirming that the byte is coming
in from PC:

Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590)
- Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590)
--- Packet 4063861
Data(1024 bytes)
Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590)
--- Packet 4063863
Data(1 byte)
Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)

According to Windows driver, no ZLP is needed if wBlockLength is non-zero,
because the non-zero wBlockLength has already told the function side the
size of transfer to be expected. However, there are in-market NCM devices
that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.
To deal with such devices, it pads an extra 0 at end so the transfer is no
longer multiple of wMaxPacketSize.

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.

*Credits: N/A
CVSS Scores
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High
* Common Vulnerability Scoring System
SSVC
  • Decision:Track*
Exploitation
None
Automatable
No
Tech. Impact
Total
* Organization's Worst-case Scenario
Timeline
  • 2024-02-25 CVE Reserved
  • 2024-05-17 CVE Published
  • 2024-05-18 EPSS Updated
  • 2024-12-19 CVE Updated
  • ---------- Exploited in Wild
  • ---------- KEV Due Date
  • ---------- First Exploit
CWE
  • CWE-476: NULL Pointer Dereference
CAPEC
Affected Vendors, Products, and Versions
Vendor Product Version Other Status
Vendor Product Version Other Status <-- --> Vendor Product Version Other Status
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.38 < 4.19.308
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.38 < 4.19.308"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.38 < 5.4.270
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.38 < 5.4.270"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.38 < 5.10.211
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.38 < 5.10.211"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.38 < 5.15.150
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.38 < 5.15.150"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.38 < 6.1.80
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.38 < 6.1.80"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.38 < 6.6.19
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.38 < 6.6.19"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.38 < 6.7.7
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.38 < 6.7.7"
en
Affected
Linux
Search vendor "Linux"
Linux Kernel
Search vendor "Linux" for product "Linux Kernel"
>= 2.6.38 < 6.8
Search vendor "Linux" for product "Linux Kernel" and version " >= 2.6.38 < 6.8"
en
Affected