Messages in this thread | | | Date | Mon, 22 Aug 2016 17:06:23 -0400 (EDT) | From | Alan Stern <> | Subject | Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 |
| |
On Mon, 22 Aug 2016, Bjørn Mork wrote:
> Alan Stern <stern@rowland.harvard.edu> writes: > > > On Mon, 22 Aug 2016, Bjørn Mork wrote: > > > >> Alan Stern <stern@rowland.harvard.edu> writes: > >> > >> > On Sun, 21 Aug 2016, Jiri Slaby wrote: > >> > > >> >> Cc: proper lists. > >> >> > >> >> ep->desc.bInterval seems to be 0 here. > > > >> > As far as I can see, this isn't possible. The usb_parse_endpoint() > >> > routine in drivers/usb/core/config.c is supposed to guarantee that > >> > ep->desc.bInterval is never 0. > >> > >> That is if it is an ISO endpoint, right? > > > > I can't tell; the bug report doesn't say. However, ep->desc.bInterval > > is ignored for bulk and control endpoints, so it must be either > > isochronous or interrupt. > > So what if the endpoint is not isochronous or interrupt here?
Oops. You're right; for some reason I thought that code was executed only if the endpoint type was known to be isochronous or interrupt.
> > USB uses two different encodings for endpoint intervals. The second > > encoding above just gives the interval in frames; this is used for low- > > and full-speed interrupt endpoints. The first encoding above is > > exponential (it gives n where the actual interval is 2^(n-1) frames or > > microframes); this is used for all isochronous endpoints and for > > high-speed (or SuperSpeed etc.) interrupt endpoints. > > OK, I am still puzzled: Won't the code I quoted above do the shift for > *any* uurb->type and endpoint type? There doesn't seem to be any test > for isochronous or interrupt endpoint around it?
Yes, that's the reason for the UBSAN report. I'll write a patch to fix it.
Alan Stern
| |