On Thu, Sep 21, 2017 at 10:17:03AM -0400, Alan Stern wrote:
> On Thu, 21 Sep 2017, Dan Carpenter wrote:
>
> > There used to be an integer overflow check in proc_do_submiturb() but
> > it accidentally got removed. We need to put it back. The
>
> The removal was deliberate, not accidental. :-)
>
> > uurb->buffer_length variable is a signed integer and it's controlled by
> > the user. It can lead to an integer overflow when we do:
> >
> > num_sgs = DIV_ROUND_UP(uurb->buffer_length, USB_SG_SIZE);
>
> Sorry, I don't understand. How can division by 16384 lead to an
> integer overflow?
>
> Now, I agree that uurb->buffer_length can cause problems. We don't
> check for meaningless negative values on all the execution paths (the
> field should have been unsigned from the beginning).
Checking against USBFS_XFER_MAX prevents negative values but I'll add
another check for readability.
> And in the
> USBDEVFS_URB_TYPE_ISO case, we overwrite uurb->buffer_length without
> checking that the new value is <= the old value, which could lead to a
> userspace buffer overflow.
Hm... Yeah. I'm not sure what's the right thing, should I print a
warning if we truncate the output or would users figure it out on their
own?
if (totlen <= uurb->buffer_length)
uurb->buffer_length = totlen;
else
WARN_ONCE(1, "uurb->buffer_length is too short %d vs %d",
totlen, uurb->buffer_length);
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
