On Sat, Oct 10, 2020 at 11:35:19AM +0200, Greg Kroah-Hartman wrote: > On Sat, Oct 10, 2020 at 01:59:32PM +0530, Anant Thazhemadam wrote: > > While finding usb endpoints in vmk80xx_find_usb_endpoints(), check if > > wMaxPacketSize = 0 for the endpoints found. > > > > Some devices have isochronous endpoints that have wMaxPacketSize = 0 > > (as required by the USB-2 spec). > > However, since this doesn't apply here, wMaxPacketSize = 0 can be > > considered to be invalid. > > > > Reported-by: syzbot+009f546aa1370056b...@syzkaller.appspotmail.com > > Tested-by: syzbot+009f546aa1370056b...@syzkaller.appspotmail.com > > Signed-off-by: Anant Thazhemadam <anant.thazhema...@gmail.com> > > --- > > Changes in v3: > > * Correctly list version information > > > > Changes in v2: > > * Fix coding style issue > > > > The error (as detected by syzbot) is generated in > > vmk80xx_write_packet() (which is called in vmk80xx_reset_device()) when > > it tries to assign devpriv->usb_tx_buf[0] = cmd. > > > > This NULL pointer dereference issue arises because > > size = usb_endpoint_maxp(devpriv->ep_tx) = 0. > > > > This can be traced back to vmk80xx_find_usb_endpoints(), where the usb > > endpoints are found, and assigned accordingly. > > (For some more insight, in vmk80xx_find_usb_endpoints(), > > if one of intf->cur_altsetting->iface_desc->endpoints' desc value = 0, > > and consequently this endpoint is assigned to devpriv->ep_tx, > > this issue gets triggered.) > > > > Checking if the wMaxPacketSize of an endpoint is invalid and returning > > an error value accordingly, seems to fix the error. > > > > We could also alternatively perform this checking (if the size is 0 or not) > > in vmk80xx_reset_device() itself, but it only seemed like covering up the > > issue > > at that place, rather than fixing it, so I wasn't sure that was any better. > > > > However, if I'm not wrong, this might end up causing the probe to fail, and > > I'm > > not sure if that's the right thing to do in cases like this, and if it > > isn't I'd > > like some input on what exactly is the required course of action in cases > > like this. > > > > drivers/staging/comedi/drivers/vmk80xx.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/staging/comedi/drivers/vmk80xx.c > > b/drivers/staging/comedi/drivers/vmk80xx.c > > index 65dc6c51037e..cb0a965d3c37 100644 > > --- a/drivers/staging/comedi/drivers/vmk80xx.c > > +++ b/drivers/staging/comedi/drivers/vmk80xx.c > > @@ -667,6 +667,9 @@ static int vmk80xx_find_usb_endpoints(struct > > comedi_device *dev) > > if (!devpriv->ep_rx || !devpriv->ep_tx) > > return -ENODEV; > > > > + if (!usb_endpoint_maxp(devpriv->ep_rx) || > > !usb_endpoint_maxp(devpriv->ep_tx)) > > + return -EINVAL; > > + > > return 0; > > } > > Why not just rewrite vmk80xx_find_usb_endpoints() to use the > usb_find_common_endpoints() or other helper functions like > usb_find_bulk_in_endpoint() or others, so that this type of thing is > checked there? > > Ah, wait, no, the packet size is not checked there, sorry, maybe that > will not help out here. Is a bulk urb allowed to have a 0 size? If > not, maybe we should just forbid that in the core? Time to go read the > USB spec...
That being said, this patch is correct, I'll go queue it up now so that it gets into 5.10-rc1. thanks, greg k-h
