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 kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
