CVE-2024-35825

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: ncm: Fix handling of zero block length packets<br /> <br /> While connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TX<br /> set to 65536, it has been observed that we receive short packets,<br /> which come at interval of 5-10 seconds sometimes and have block<br /> length zero but still contain 1-2 valid datagrams present.<br /> <br /> According to the NCM spec:<br /> <br /> "If wBlockLength = 0x0000, the block is terminated by a<br /> short packet. In this case, the USB transfer must still<br /> be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If<br /> exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent,<br /> and the size is a multiple of wMaxPacketSize for the<br /> given pipe, then no ZLP shall be sent.<br /> <br /> wBlockLength= 0x0000 must be used with extreme care, because<br /> of the possibility that the host and device may get out of<br /> sync, and because of test issues.<br /> <br /> wBlockLength = 0x0000 allows the sender to reduce latency by<br /> starting to send a very large NTB, and then shortening it when<br /> the sender discovers that there’s not sufficient data to justify<br /> sending a large NTB"<br /> <br /> However, there is a potential issue with the current implementation,<br /> as it checks for the occurrence of multiple NTBs in a single<br /> giveback by verifying if the leftover bytes to be processed is zero<br /> or not. If the block length reads zero, we would process the same<br /> NTB infintely because the leftover bytes is never zero and it leads<br /> to a crash. Fix this by bailing out if block length reads zero.