CVE-2024-27405 in Linux
Sumário
de VulDB • 05/06/2026
No kernel do Linux, a seguinte vulnerabilidade foi resolvida:
usb: gadget: ncm: Evitar a perda de datagramas de NTBs analisados corretamente
Observa-se, por vezes, quando o tethering é utilizado via NCM com o Windows 11 como host, que em algumas instâncias, a função gadget_giveback tem um byte anexado ao final de um NTB válido. Ao analisar o NTB, a chamada unwrap procura por quaisquer bytes restantes no SKB fornecido por u_ether e, se houver bytes pendentes, trata-os como um NTB separado e o analisa. No entanto, caso o segundo NTB (conforme a chamada unwrap) esteja defeituoso ou corrompido, todos os datagramas que foram analisados corretamente no primeiro NTB e salvos em rx_list são descartados.
A adição de alguns rastreamentos personalizados mostrou o seguinte: [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
Neste caso, o giveback é de 1025 bytes e o comprimento do bloco é 1024. Os 1 byte restantes (que é 0x00) não serão analisados, resultando na queda de todos os datagramas em rx_list.
O mesmo ocorre com pacotes de tamanho 2048: [002] d..1 7828.557948: dwc3_gadget_giveback: ep1out:
req 000000003868811a length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 2049
[002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
[002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67
[002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800
[002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10
[002] d..1 7828.557951: ncm_unwrap_ntb: K: Parsed NTB com 1 frames
O LeCroy mostra um byte a mais sendo recebido, confirmando que o byte está sendo enviado pelo 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)
De acordo com o driver do Windows, nenhum ZLP é necessário se wBlockLength for diferente de zero, porque o wBlockLength não nulo já informou ao lado da função o tamanho da transferência a ser esperado. No entanto, existem dispositivos NCM em campo que dependem de ZLP enquanto wBlockLength for múltiplo de wMaxPacketSize. Para lidar com esses dispositivos, ele preenche um 0 extra no final para que a transferência não seja mais múltipla de wMaxPacketSize.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.