Re: [PATCH v2] usb: usbtmc: reject invalid interrupt endpoints

[Michal Pecio]

On Thu, 23 Apr 2026 15:04:38 -0300, Heitor Alves de Siqueira wrote:
> The USBTMC driver allocates the Interrupt-IN buffer according to the
> wMaxPacketSize value obtained from the USB endpoint. If a USB device
> advertises a small enough wMaxPacketSize (e.g. a malfunctioning device
> or an endpoint constructed by syzbot), the buffer will not have enough
> space for the mandatory headers and will trigger an out-of-bounds read.
> 
> Fix by rejecting devices advertising interrupt endpoints that don't fit
> at least the mandatory headers (bNotify1 and bNotify2).
> 
> Fixes: dbf3e7f654c0 ("Implement an ioctl to support the USMTMC-USB488 READ_STATUS_BYTE operation.")
> Reported-by: syzbot+abbfd103085885cf16a2@xxxxxxxxxxxxxxxxxxxxxxxxx
> Closes: https://syzkaller.appspot.com/bug?extid=abbfd103085885cf16a2
> Cc: stable@xxxxxxxxxx
> Suggested-by: Michal Pecio <michal.pecio@xxxxxxxxx>
> Signed-off-by: Heitor Alves de Siqueira <halves@xxxxxxxxxx>
> ---
> Changes in v2:
> - Instead of ensuring buffer size, reject devices that advertise illegal/invalid interrupt endpoints
> - Link to v1: https://patch.msgid.link/20260422-usbtmc-iin-size-v1-1-5dc44b4389aa@xxxxxxxxxx

On second thought, this may be not enough. A wMaxPacketSize == 2 device
can still send only 1 byte (or even 0) and cause unititialized read.
Better check if the URB completed with expected actual_length before
trying to parse the message.

And by the way, an interrupt transfer may span multiple intervals and
exceed wMaxPacketSize, USBTMC spec alludes to it. Theoretically, even
wMaxPacketSize == 1 seems possible, though it would be crazy and likely
no such HW exists because nobody complains that it doesn't work.

Regards,
Michal