Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1468059
| From | Alan Stern <stern@rowland.harvard.edu> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 |
| Date | 2016-08-22 23:10 +0200 |
| Message-ID | <s94DL-36M-15@gated-at.bofh.it> (permalink) |
| References | <s94u6-2Ol-47@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 Jiri Slaby <jslaby@suse.cz> - 2016-08-21 12:50 +0200
Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 Alan Stern <stern@rowland.harvard.edu> - 2016-08-22 19:50 +0200
Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 Bjørn Mork <bjorn@mork.no> - 2016-08-22 22:30 +0200
Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 Alan Stern <stern@rowland.harvard.edu> - 2016-08-22 22:50 +0200
Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 Bjørn Mork <bjorn@mork.no> - 2016-08-22 23:00 +0200
Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 Alan Stern <stern@rowland.harvard.edu> - 2016-08-22 23:10 +0200
Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 Vittorio Zecca <zeccav@gmail.com> - 2016-08-22 23:50 +0200
Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 Alan Stern <stern@rowland.harvard.edu> - 2016-08-23 17:10 +0200
Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 Vittorio Zecca <zeccav@gmail.com> - 2016-08-23 18:00 +0200
Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 Alan Stern <stern@rowland.harvard.edu> - 2016-08-23 21:00 +0200
csiph-web