* Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 [not found] <CAFQ=mRQeV_UHYuU20ppHG6L=mNcr_cKxBMMM731XfWeoEO-L=g@mail.gmail.com> @ 2016-08-21 10:46 ` Jiri Slaby 2016-08-22 17:43 ` Alan Stern 0 siblings, 1 reply; 10+ messages in thread From: Jiri Slaby @ 2016-08-21 10:46 UTC (permalink / raw) To: Vittorio Zecca, stable, USB list, Linux kernel mailing list Cc: proper lists. ep->desc.bInterval seems to be 0 here. On 08/21/2016, 12:42 PM, Vittorio Zecca wrote: > I am not sure this is the right place so please bear with me... > From Vittorio Zecca > > After compiling kernel 4.7.2 with ubsan I got the following messages > at boot time: > > (devio.c:1713 is "as->urb->interval = 1 << min(15, ep->desc.bInterval - 1);") > > [ +0.354486] ================================================================================ > [ +0.000008] UBSAN: Undefined behaviour in > /home/vitti/1tb/vitti/rpmbuild/SOURCES/linux-4.7.2/drivers/usb/core/devio.c:1713:25 > [ +0.000004] shift exponent -1 is negative > [ +0.000005] CPU: 1 PID: 616 Comm: mtp-probe Not tainted 4.7.2sanitized #1 > [ +0.000004] Hardware name: To Be Filled By O.E.M. To Be Filled By > O.E.M./H81M-DGS R2.0, BIOS P1.30 07/02/2014 > [ +0.000003] ffffffff845f1d00 000000006774dd2e ffff880382e5f758 > ffffffff818cad70 > [ +0.000005] 0000000041b58ab3 ffffffff829ffc3e ffffffff818cacbe > ffff880382e5f780 > [ +0.000005] ffff880382e5f730 ffffffffffffffff ffff880382e5f800 > ffffffff845f1d00 > [ +0.000004] Call Trace: > [ +0.000009] [<ffffffff818cad70>] dump_stack+0xb2/0x103 > [ +0.000006] [<ffffffff818cacbe>] ? _atomic_dec_and_lock+0x190/0x190 > [ +0.000005] [<ffffffff819511e3>] ubsan_epilogue+0xd/0x4e > [ +0.000005] [<ffffffff81951cad>] > __ubsan_handle_shift_out_of_bounds+0x1f4/0x24c > [ +0.000005] [<ffffffff81951ab9>] ? > __ubsan_handle_load_invalid_value+0x153/0x153 > [ +0.000007] [<ffffffff81d23fe8>] ? proc_do_submiturb+0xdde/0x21a6 > [ +0.000005] [<ffffffff814be72c>] ? memset+0x31/0x38 > [ +0.000005] [<ffffffff81d099c6>] ? usb_alloc_urb+0xd5/0x13a > [ +0.000004] [<ffffffff814be5bf>] ? kasan_unpoison_shadow+0x35/0x43 > [ +0.000004] [<ffffffff814be5bf>] ? kasan_unpoison_shadow+0x35/0x43 > [ +0.000004] [<ffffffff814be62b>] ? kasan_kmalloc+0x5e/0x64 > [ +0.000005] [<ffffffff814b8c1a>] ? __kmalloc+0x143/0x40f > [ +0.000005] [<ffffffff818f13f1>] ? lockref_put_or_lock+0x8f/0x227 > [ +0.000006] [<ffffffff81d24f02>] proc_do_submiturb+0x1cf8/0x21a6 > [ +0.000004] [<ffffffff81d24f02>] ? proc_do_submiturb+0x1cf8/0x21a6 > [ +0.000006] [<ffffffff813e2df8>] ? __alloc_pages_nodemask+0x26a/0x1ebe > [ +0.000004] [<ffffffff8151635c>] ? cdev_put.part.0+0x46/0x46 > [ +0.000005] [<ffffffff818f15ea>] ? lockref_mark_dead+0x61/0x61 > [ +0.000005] [<ffffffff81d2320a>] ? usbdev_release+0x223/0x223 > [ +0.000005] [<ffffffff813e2b8e>] ? warn_alloc_failed+0x266/0x266 > [ +0.000004] [<ffffffff8155a22a>] ? mntput+0x3b/0x5e > [ +0.000005] [<ffffffff81522f5c>] ? terminate_walk+0xfe/0x2cb > [ +0.000005] [<ffffffff81509cf6>] ? vfs_open+0xb7/0x14f > [ +0.000005] [<ffffffff81d26801>] usbdev_do_ioctl+0x1451/0x25c7 > [ +0.000004] [<ffffffff81d253b0>] ? proc_do_submiturb+0x21a6/0x21a6 > [ +0.000005] [<ffffffff81550407>] ? atime_needs_update+0x28f/0x36c > [ +0.000005] [<ffffffff81550178>] ? new_inode+0x30/0x30 > [ +0.000005] [<ffffffff822087ad>] ? _raw_spin_unlock_bh+0xbf/0xbf > [ +0.000006] [<ffffffff8124f149>] ? enqueue_hrtimer+0x91/0x1c0 > [ +0.000005] [<ffffffff8124edab>] ? lock_hrtimer_base+0x6b/0xc9 > [ +0.000005] [<ffffffff812509a1>] ? hrtimer_start_range_ns+0x4ab/0xba9 > [ +0.000004] [<ffffffff812504f6>] ? hrtimer_init+0xe8/0xe8 > [ +0.000005] [<ffffffff8124f65c>] ? __hrtimer_init+0xe5/0x13f > [ +0.000005] [<ffffffff81d27999>] usbdev_ioctl+0xe/0x12 > [ +0.000004] [<ffffffff81537d1f>] do_vfs_ioctl+0x170/0xc6f > [ +0.000005] [<ffffffff815bf17b>] ? do_timerfd_settime+0x483/0x7d8 > [ +0.000004] [<ffffffff81537baf>] ? ioctl_preallocate+0x1e3/0x1e3 > [ +0.000004] [<ffffffff815becf8>] ? timerfd_release+0x91/0x91 > [ +0.000005] [<ffffffff815c0247>] ? SyS_timerfd_settime+0xbd/0x143 > [ +0.000005] [<ffffffff81551968>] ? __fget+0xde/0x1ee > [ +0.000005] [<ffffffff81552695>] ? __fget_light+0xdd/0x14f > [ +0.000004] [<ffffffff81538897>] SyS_ioctl+0x79/0x92 > [ +0.000005] [<ffffffff82208d72>] entry_SYSCALL_64_fastpath+0x1a/0xa4 > [ +0.000003] ================================================================================ > [ +0.424947] usbcore: registered new interface driver option > [ +0.000503] usbserial: USB Serial support registered for GSM modem (1-port) > [ +0.000363] option 3-8:1.0: GSM modem (1-port) converter detected > [ +0.003096] usb 3-8: GSM modem (1-port) converter now attached to ttyUSB0 > [ +0.000239] option 3-8:1.2: GSM modem (1-port) converter detected > [ +0.003003] usb 3-8: GSM modem (1-port) converter now attached to ttyUSB1 > [ +0.000198] option 3-8:1.3: GSM modem (1-port) converter detected > [ +0.002997] usb 3-8: GSM modem (1-port) converter now attached to ttyUSB2 > [ +0.855356] iTCO_vendor_support: vendor-support=0 > [ +0.334571] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11 > [ +0.000380] iTCO_wdt: Found a Lynx Point TCO device (Version=2, > TCOBASE=0x1860) > [ +0.003131] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) > [ +0.433888] usbcore: registered new interface driver cdc_ncm > [ +0.056852] ppdev: user-space parallel port driver > [ +0.681019] usbcore: registered new interface driver cdc_wdm > [ +0.746911] huawei_cdc_ncm 3-8:1.1: MAC-Address: 58:2c:80:13:92:63 > [ +0.000009] huawei_cdc_ncm 3-8:1.1: setting rx_max = 16384 > [ +0.000443] huawei_cdc_ncm 3-8:1.1: setting tx_max = 16384 > [ +0.000391] huawei_cdc_ncm 3-8:1.1: NDP will be placed at end of > frame for this device. > [ +0.002619] huawei_cdc_ncm 3-8:1.1: cdc-wdm0: USB WDM device > [ +0.009247] huawei_cdc_ncm 3-8:1.1 wwan0: register 'huawei_cdc_ncm' > at usb-0000:00:14.0-8, Huawei CDC NCM device, 58:2c:80:13:92:63 > [ +0.000693] usbcore: registered new interface driver huawei_cdc_ncm > [ +0.081877] huawei_cdc_ncm 3-8:1.1 wwp0s20u8i1: renamed from wwan0 > -- > To unsubscribe from this list: send the line "unsubscribe stable" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- js suse labs ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 2016-08-21 10:46 ` UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 Jiri Slaby @ 2016-08-22 17:43 ` Alan Stern 2016-08-22 20:21 ` Bjørn Mork 0 siblings, 1 reply; 10+ messages in thread From: Alan Stern @ 2016-08-22 17:43 UTC (permalink / raw) To: Jiri Slaby; +Cc: Vittorio Zecca, stable, USB list, Linux kernel mailing list On Sun, 21 Aug 2016, Jiri Slaby wrote: > Cc: proper lists. > > ep->desc.bInterval seems to be 0 here. > > On 08/21/2016, 12:42 PM, Vittorio Zecca wrote: > > I am not sure this is the right place so please bear with me... > > From Vittorio Zecca > > > > After compiling kernel 4.7.2 with ubsan I got the following messages > > at boot time: > > > > (devio.c:1713 is "as->urb->interval = 1 << min(15, ep->desc.bInterval - 1);") > > > > [ +0.354486] ================================================================================ > > [ +0.000008] UBSAN: Undefined behaviour in > > /home/vitti/1tb/vitti/rpmbuild/SOURCES/linux-4.7.2/drivers/usb/core/devio.c:1713:25 > > [ +0.000004] shift exponent -1 is negative 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. More information from Vittorio would be helpful. For example, what shows up in /sys/kernel/debug/usb/devices (after mounting a debugfs filesystem on /sys/kernel/debug)? Alan Stern ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 2016-08-22 17:43 ` Alan Stern @ 2016-08-22 20:21 ` Bjørn Mork 2016-08-22 20:40 ` Alan Stern 0 siblings, 1 reply; 10+ messages in thread From: Bjørn Mork @ 2016-08-22 20:21 UTC (permalink / raw) To: Alan Stern Cc: Jiri Slaby, Vittorio Zecca, stable, USB list, Linux kernel mailing list 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. >> >> On 08/21/2016, 12:42 PM, Vittorio Zecca wrote: >> > I am not sure this is the right place so please bear with me... >> > From Vittorio Zecca >> > >> > After compiling kernel 4.7.2 with ubsan I got the following messages >> > at boot time: >> > >> > (devio.c:1713 is "as->urb->interval = 1 << min(15, ep->desc.bInterval - 1);") >> > >> > [ +0.354486] ================================================================================ >> > [ +0.000008] UBSAN: Undefined behaviour in >> > /home/vitti/1tb/vitti/rpmbuild/SOURCES/linux-4.7.2/drivers/usb/core/devio.c:1713:25 >> > [ +0.000004] shift exponent -1 is negative > > 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? Maybe I misunderstand something fundamental, but the "||" strikes me as odd here: as->urb->stream_id = stream_id; if (uurb->type == USBDEVFS_URB_TYPE_ISO || ps->dev->speed == USB_SPEED_HIGH) as->urb->interval = 1 << min(15, ep->desc.bInterval - 1); else as->urb->interval = ep->desc.bInterval; as->urb->context = as; Typo? Bjørn ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 2016-08-22 20:21 ` Bjørn Mork @ 2016-08-22 20:40 ` Alan Stern 2016-08-22 20:57 ` Bjørn Mork 0 siblings, 1 reply; 10+ messages in thread From: Alan Stern @ 2016-08-22 20:40 UTC (permalink / raw) To: Bjørn Mork Cc: Jiri Slaby, Vittorio Zecca, stable, USB list, Linux kernel mailing list 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. > Maybe I misunderstand something fundamental, but the "||" strikes me as > odd here: > > as->urb->stream_id = stream_id; > if (uurb->type == USBDEVFS_URB_TYPE_ISO || > ps->dev->speed == USB_SPEED_HIGH) > as->urb->interval = 1 << min(15, ep->desc.bInterval - 1); > else > as->urb->interval = ep->desc.bInterval; > as->urb->context = as; No, that's right (mostly -- we really should check for ps->dev->speed >= USB_SPEED_SUPER as well as == USB_SPEED_HIGH). > Typo? 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. See for example the definition of usb_fill_int_urb() in include/linux/usb.h. Alan Stern ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 2016-08-22 20:40 ` Alan Stern @ 2016-08-22 20:57 ` Bjørn Mork 2016-08-22 21:06 ` Alan Stern 0 siblings, 1 reply; 10+ messages in thread From: Bjørn Mork @ 2016-08-22 20:57 UTC (permalink / raw) To: Alan Stern Cc: Jiri Slaby, Vittorio Zecca, stable, USB list, Linux kernel mailing list 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? >> Maybe I misunderstand something fundamental, but the "||" strikes me as >> odd here: >> >> as->urb->stream_id = stream_id; >> if (uurb->type == USBDEVFS_URB_TYPE_ISO || >> ps->dev->speed == USB_SPEED_HIGH) >> as->urb->interval = 1 << min(15, ep->desc.bInterval - 1); >> else >> as->urb->interval = ep->desc.bInterval; >> as->urb->context = as; > > No, that's right (mostly -- we really should check for ps->dev->speed >>= USB_SPEED_SUPER as well as == USB_SPEED_HIGH). > >> Typo? > > 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? Bjørn ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 2016-08-22 20:57 ` Bjørn Mork @ 2016-08-22 21:06 ` Alan Stern 2016-08-22 21:45 ` Vittorio Zecca 0 siblings, 1 reply; 10+ messages in thread From: Alan Stern @ 2016-08-22 21:06 UTC (permalink / raw) To: Bjørn Mork Cc: Jiri Slaby, Vittorio Zecca, stable, USB list, Linux kernel mailing list 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 2016-08-22 21:06 ` Alan Stern @ 2016-08-22 21:45 ` Vittorio Zecca 2016-08-23 14:55 ` Alan Stern 0 siblings, 1 reply; 10+ messages in thread From: Vittorio Zecca @ 2016-08-22 21:45 UTC (permalink / raw) To: Alan Stern Cc: Bjørn Mork, Jiri Slaby, stable, USB list, Linux kernel mailing list I can reproduce the UBSAN report by inserting in the USB receptacle a HUAWEI Mobile Broadband E353 HSPA+ USB Stick. Alan Stern asked for /sys/kernel/debug/usb/devices: cat debug-usb-devices T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 4.07 S: Manufacturer=Linux 4.7.2sanitized ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=0000:00:1a.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 4 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=8008 Rev= 0.05 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms T: Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 2 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 4.07 S: Manufacturer=Linux 4.7.2sanitized ehci_hcd S: Product=EHCI Host Controller S: SerialNumber=0000:00:1d.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 6 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=8087 ProdID=8000 Rev= 0.05 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=256ms T: Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh=10 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=1d6b ProdID=0002 Rev= 4.07 S: Manufacturer=Linux 4.7.2sanitized xhci-hcd S: Product=xHCI Host Controller S: SerialNumber=0000:00:14.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms T: Bus=03 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 2 Spd=1.5 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=15d9 ProdID=0a37 Rev= 1.00 S: Product=USB Mouse C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=10ms T: Bus=03 Lev=01 Prnt=01 Port=06 Cnt=02 Dev#= 3 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=12d1 ProdID=1506 Rev= 1.02 S: Manufacturer=HUAWEI S: Product=HUAWEI Mobile C:* #Ifs= 6 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=option E: Ad=8f(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I: If#= 1 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=16 Driver=huawei_cdc_ncm E: Ad=8d(I) Atr=03(Int.) MxPS= 64 Ivl=2ms I:* If#= 1 Alt= 1 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=16 Driver=huawei_cdc_ncm E: Ad=8d(I) Atr=03(Int.) MxPS= 64 Ivl=2ms E: Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0e(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=03 Driver=option E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0d(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=02 Driver=option E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=0b(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=0a(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms T: Bus=03 Lev=01 Prnt=01 Port=08 Cnt=03 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=05e3 ProdID=070e Rev=93.17 S: Manufacturer=Genesys S: Product=USB Reader S: SerialNumber=000000245202 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms T: Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=5000 MxCh= 2 B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0 D: Ver= 3.00 Cls=09(hub ) Sub=00 Prot=03 MxPS= 9 #Cfgs= 1 P: Vendor=1d6b ProdID=0003 Rev= 4.07 S: Manufacturer=Linux 4.7.2sanitized xhci-hcd S: Product=xHCI Host Controller S: SerialNumber=0000:00:14.0 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 4 Ivl=256ms [vitti ~]$ If there is any patch I'll be happy to try it. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 2016-08-22 21:45 ` Vittorio Zecca @ 2016-08-23 14:55 ` Alan Stern 2016-08-23 15:47 ` Vittorio Zecca 0 siblings, 1 reply; 10+ messages in thread From: Alan Stern @ 2016-08-23 14:55 UTC (permalink / raw) To: Vittorio Zecca Cc: Bjørn Mork, Jiri Slaby, stable, USB list, Linux kernel mailing list On Mon, 22 Aug 2016, Vittorio Zecca wrote: > I can reproduce the UBSAN report by inserting in the USB receptacle a > HUAWEI Mobile Broadband E353 HSPA+ USB Stick. > If there is any patch I'll be happy to try it. Thank you. Please let us know what happens with the patch below. Alan Stern Index: usb-4.x/drivers/usb/core/devio.c =================================================================== --- usb-4.x.orig/drivers/usb/core/devio.c +++ usb-4.x/drivers/usb/core/devio.c @@ -1709,11 +1709,17 @@ static int proc_do_submiturb(struct usb_ as->urb->start_frame = uurb->start_frame; as->urb->number_of_packets = number_of_packets; as->urb->stream_id = stream_id; - if (uurb->type == USBDEVFS_URB_TYPE_ISO || - ps->dev->speed == USB_SPEED_HIGH) - as->urb->interval = 1 << min(15, ep->desc.bInterval - 1); - else - as->urb->interval = ep->desc.bInterval; + + if (ep->desc.bInterval) { + if (uurb->type == USBDEVFS_URB_TYPE_ISO || + ps->dev->speed == USB_SPEED_HIGH || + ps->dev->speed >= USB_SPEED_SUPER) + as->urb->interval = 1 << + min(15, ep->desc.bInterval - 1); + else + as->urb->interval = ep->desc.bInterval; + } + as->urb->context = as; as->urb->complete = async_completed; for (totlen = u = 0; u < number_of_packets; u++) { ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 2016-08-23 14:55 ` Alan Stern @ 2016-08-23 15:47 ` Vittorio Zecca 2016-08-23 18:58 ` Alan Stern 0 siblings, 1 reply; 10+ messages in thread From: Vittorio Zecca @ 2016-08-23 15:47 UTC (permalink / raw) To: Alan Stern Cc: Bjørn Mork, Jiri Slaby, stable, USB list, Linux kernel mailing list After applying the patch above the UBSAN issue in devio.c disappeared. However, I got the following messages in dmesg, probably due to a NetworkManager malfunctioning, and if I click on the NetworkManager icon I get "NetworkManager is not running" but maybe this is another issue and your patch did solve the devio.c problem. Unfortunately I cannot use the 4.7.2 kernel with ubsan and asan because I need the networkmanager running, as it is doing now on kernel version 4.6.6 [ +0.648205] BUG: unable to handle kernel paging request at ffff8272d6400205 [ +0.000118] IP: [<ffffffff818e11d4>] strcmp+0x48/0x8b [ +0.000075] PGD 0 [ +0.000033] Oops: 0000 [#1] SMP KASAN [ +0.000051] Modules linked in: ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw intel_rapl x86_pkg_temp_thermal coretemp kvm_intel kvm snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core huawei_cdc_ncm snd_hwdep snd_seq irqbypass cdc_wdm ppdev crct10dif_pclmul cdc_ncm snd_seq_device iTCO_wdt option iTCO_vendor_support crc32_pclmul snd_pcm crc32c_intel usb_wwan usbnet ghash_clmulni_intel snd_timer parport_pc i2c_i801 snd nuvoton_cir pcspkr mei_me parport soc_button_array mei rc_core [ +0.001125] shpchp lpc_ich soundcore tpm_tis tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc i915 i2c_algo_bit drm_kms_helper r8169 drm serio_raw mii video fjes uas usb_storage [ +0.000265] CPU: 1 PID: 856 Comm: NetworkManager Not tainted 4.7.2sanitized #4 [ +0.000094] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H81M-DGS R2.0, BIOS P1.30 07/02/2014 [ +0.000127] task: ffff8800346f9e00 ti: ffff8800d5df8000 task.ti: ffff8800d5df8000 [ +0.000096] RIP: 0010:[<ffffffff818e11d4>] [<ffffffff818e11d4>] strcmp+0x48/0x8b [ +0.000104] RSP: 0018:ffff8800d5dfed28 EFLAGS: 00010246 [ +0.000071] RAX: 0000000000000000 RBX: ffffffffc0263c20 RCX: ffffffff818e11d4 [ +0.000093] RDX: 1ffff04e5ac80040 RSI: ffff8272d6400205 RDI: ffff8272d6400205 [ +0.000093] RBP: ffff8800d5dfed50 R08: ffff880389669150 R09: ffffed00712cd3d2 [ +0.000092] R10: ffff8800346f9e00 R11: 0000000000000010 R12: ffff8272d6400205 [ +0.000092] R13: 0000000000000072 R14: ffffffffc0263c21 R15: ffff8272d6400206 [ +0.000093] FS: 00007fce6294e880(0000) GS:ffff88038ed00000(0000) knlGS:0000000000000000 [ +0.000103] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.002818] CR2: ffff8272d6400205 CR3: 00000000350b6000 CR4: 00000000000406e0 [ +0.002903] Stack: [ +0.002833] ffffffff82aa6a78 1ffff1001abbfdaf ffff880384ba0b80 ffffffffc0263c20 [ +0.000047] ffff880389669e70 [ +0.000001] ffff8800d5dfee00 [ +0.000001] ffffffff81bf33dd [ +0.000000] ffff88038b1c8000 [ +0.000001] 00000000026040c0 [ +0.000001] ffff88038c7fc560 [ +0.000000] 0000000041b58ab3 [ +0.000001] ffffffff82a70a84 [ +0.000001] Call Trace: [ +0.000007] [<ffffffff81bf33dd>] _request_firmware+0x156/0x274 [ +0.000004] [<ffffffff81bf3287>] ? request_firmware_nowait+0x2ad/0x2ad [ +0.000004] [<ffffffff814be62b>] ? kasan_kmalloc+0x5e/0x64 [ +0.000004] [<ffffffff814b67b6>] ? kmem_cache_alloc_trace+0x124/0x390 [ +0.000004] [<ffffffff81bf352c>] request_firmware+0x31/0x43 [ +0.000009] [<ffffffffc025d7a7>] rtl_open+0x1133/0x1b3a [r8169] [ +0.000009] [<ffffffffc025c674>] ? rtl_remove_one+0x35d/0x35d [r8169] [ +0.000004] [<ffffffff821da57f>] ? packet_notifier+0xdb/0x593 [ +0.000004] [<ffffffff821da4a4>] ? register_prot_hook.part.17+0x6e/0x6e [ +0.000003] [<ffffffff821bc032>] ? ip6mr_device_event+0xa6/0x276 [ +0.000003] [<ffffffff821bbf8c>] ? mif6_delete+0x41c/0x41c [ +0.000014] [<ffffffffc16101a1>] ? br_device_event+0x41/0x360 [bridge] [ +0.000005] [<ffffffff8119993a>] ? raw_notifier_call_chain+0x85/0xec [ +0.000005] [<ffffffff81f7d103>] __dev_open+0x161/0x24c [ +0.000002] [<ffffffff81f7cfa2>] ? dev_set_rx_mode+0x33/0x33 [ +0.000003] [<ffffffff81f7cdf0>] ? __dev_set_rx_mode+0x3d/0x1bc [ +0.000003] [<ffffffff81f7d611>] __dev_change_flags+0xe8/0x229 [ +0.000003] [<ffffffff81f7d7af>] dev_change_flags+0x5d/0xbd [ +0.000004] [<ffffffff81f9e31e>] do_setlink+0x628/0x1c26 [ +0.000003] [<ffffffff813e2df8>] ? __alloc_pages_nodemask+0x26a/0x1ebe [ +0.000003] [<ffffffff81f9dcf6>] ? rtnl_unregister+0x201/0x201 [ +0.000004] [<ffffffff814b3841>] ? alloc_debug_processing+0x56/0x36e [ +0.000003] [<ffffffff813e2df8>] ? __alloc_pages_nodemask+0x26a/0x1ebe [ +0.000003] [<ffffffff813e2b8e>] ? warn_alloc_failed+0x266/0x266 [ +0.000003] [<ffffffff812059ad>] ? __init_rwsem+0xfd/0x17c [ +0.000004] [<ffffffff812058b0>] ? rt_mutex_finish_proxy_lock+0x1bd/0x1bd [ +0.000005] [<ffffffff81307a48>] ? is_ftrace_trampoline+0x62/0xaf [ +0.000003] [<ffffffff81192ff7>] ? __kernel_text_address+0x63/0x82 [ +0.000004] [<ffffffff8106decc>] ? print_context_stack+0x7e/0x177 [ +0.000002] [<ffffffff814be72c>] ? memset+0x31/0x38 [ +0.000004] [<ffffffff8194332b>] ? nla_parse+0xa1/0x2d9 [ +0.000003] [<ffffffff81f9cb88>] ? validate_linkmsg+0x140/0x3df [ +0.000003] [<ffffffff81f9ca48>] ? rtnl_link_get_net+0xf3/0xf3 [ +0.000003] [<ffffffff81307a48>] ? is_ftrace_trampoline+0x62/0xaf [ +0.000003] [<ffffffff81fa09a3>] rtnl_newlink+0x9c8/0xf17 [ +0.000003] [<ffffffff81fa0679>] ? rtnl_newlink+0x69e/0xf17 [ +0.000003] [<ffffffff81f9ffdb>] ? rtnetlink_put_metrics+0x454/0x454 [ +0.000004] [<ffffffff81192ff7>] ? __kernel_text_address+0x63/0x82 [ +0.000003] [<ffffffff8106decc>] ? print_context_stack+0x7e/0x177 [ +0.000004] [<ffffffff81791a03>] ? cap_capable+0xc3/0x134 [ +0.000003] [<ffffffff817963e2>] ? security_capable+0x3c/0x8f [ +0.000003] [<ffffffff811619cf>] ? ns_capable+0x60/0xb9 [ +0.000004] [<ffffffff81feec1f>] ? __netlink_ns_capable+0x80/0xba [ +0.000003] [<ffffffff81f9ffdb>] ? rtnetlink_put_metrics+0x454/0x454 [ +0.000003] [<ffffffff81f9be12>] rtnetlink_rcv_msg+0x1e0/0x8fc [ +0.000003] [<ffffffff81f425a0>] ? __alloc_skb+0xb6/0x414 [ +0.000003] [<ffffffff81f9bc32>] ? rtnl_link_unregister+0x213/0x213 [ +0.000002] [<ffffffff81ff2bca>] ? netlink_lookup+0x1cf/0x2b2 [ +0.000003] [<ffffffff81ff29fb>] ? netlink_broadcast+0x1f/0x1f [ +0.000003] [<ffffffff81ff7843>] netlink_rcv_skb+0x147/0x1bb [ +0.000003] [<ffffffff81f9bc32>] ? rtnl_link_unregister+0x213/0x213 [ +0.000003] [<ffffffff81f98fb6>] rtnetlink_rcv+0x28/0x30 [ +0.000002] [<ffffffff81ff6a1f>] netlink_unicast+0x33f/0x472 [ +0.000003] [<ffffffff81ff66e0>] ? netlink_attachskb+0x49a/0x49a [ +0.000002] [<ffffffff814be51c>] ? kasan_check_write+0x14/0x16 [ +0.000003] [<ffffffff818faef0>] ? copy_from_iter+0x17d/0x5e2 [ +0.000003] [<ffffffff81ff71ff>] netlink_sendmsg+0x6ad/0x89c [ +0.000003] [<ffffffff81ff6b52>] ? netlink_unicast+0x472/0x472 [ +0.000003] [<ffffffff81ff6b52>] ? netlink_unicast+0x472/0x472 [ +0.000004] [<ffffffff81f2d710>] sock_sendmsg+0x84/0xcc [ +0.000003] [<ffffffff81f2eb1f>] ___sys_sendmsg+0x51b/0x5da [ +0.000003] [<ffffffff8162e8ea>] ? unuse_table.part.3+0x1b/0x42 [ +0.000003] [<ffffffff81f2e604>] ? copy_msghdr_from_user+0x2b6/0x2b6 [ +0.000003] [<ffffffff81160007>] ? proc_dointvec+0x5c/0x7b [ +0.000003] [<ffffffff8162f126>] ? proc_sys_call_handler+0x112/0x1d8 [ +0.000004] [<ffffffff812358c0>] ? __call_rcu_nocb_enqueue+0x140/0x31d [ +0.000002] [<ffffffff8162f014>] ? proc_sys_poll+0x1a2/0x1a2 [ +0.000004] [<ffffffff818f14e4>] ? lockref_put_or_lock+0x182/0x227 [ +0.000003] [<ffffffff818f1362>] ? lockref_get_or_lock+0x247/0x247 [ +0.000003] [<ffffffff81551968>] ? __fget+0xde/0x1ee [ +0.000003] [<ffffffff81552695>] ? __fget_light+0xdd/0x14f [ +0.000003] [<ffffffff8155271a>] ? __fdget+0x13/0x15 [ +0.000003] [<ffffffff81f2fe24>] __sys_sendmsg+0xcb/0x145 [ +0.000003] [<ffffffff81f2fd59>] ? SyS_shutdown+0x170/0x170 [ +0.000003] [<ffffffff815114a1>] ? __fput+0x262/0x3e7 [ +0.000004] [<ffffffff814eb849>] ? mem_cgroup_handle_over_high+0x7a/0x1f5 [ +0.000002] [<ffffffff814eb7cf>] ? mem_cgroup_oom_synchronize+0x72e/0x72e [ +0.000003] [<ffffffff8151168a>] ? ____fput+0xe/0x10 [ +0.000003] [<ffffffff81f2feb0>] SyS_sendmsg+0x12/0x1c [ +0.000004] [<ffffffff82226d72>] entry_SYSCALL_64_fastpath+0x1a/0xa4 [ +0.000025] Code: 4d 89 fc 4c 8d 73 01 48 85 db 74 52 48 89 df e8 a6 cd bd ff 45 0f b6 6e ff 4d 8d 7c 24 01 4d 85 e4 74 2b 4c 89 e7 e8 8f cd bd ff <45> 3a 6f ff 74 c7 19 c0 83 c8 01 5b 41 5c 41 5d 41 5e 41 5f 5d [ +0.000003] RIP [<ffffffff818e11d4>] strcmp+0x48/0x8b [ +0.000000] RSP <ffff8800d5dfed28> [ +0.000001] CR2: ffff8272d6400205 [ +0.012995] ---[ end trace aed6c80e54c9629a ]--- [Aug23 17:34] usb 3-8: USB disconnect, device number 3 [ +0.005711] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0 [ +0.001105] option 3-8:1.0: device disconnected [ +0.003580] huawei_cdc_ncm 3-8:1.1 wwp0s20u8i1: unregister 'huawei_cdc_ncm' usb-0000:00:14.0-8, Huawei CDC NCM device ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 2016-08-23 15:47 ` Vittorio Zecca @ 2016-08-23 18:58 ` Alan Stern 0 siblings, 0 replies; 10+ messages in thread From: Alan Stern @ 2016-08-23 18:58 UTC (permalink / raw) To: Vittorio Zecca Cc: Bjørn Mork, Jiri Slaby, stable, USB list, Linux kernel mailing list On Tue, 23 Aug 2016, Vittorio Zecca wrote: > After applying the patch above the UBSAN issue in devio.c disappeared. > > However, I got the following messages in dmesg, probably due to a NetworkManager > malfunctioning, and if I click on the NetworkManager icon I get > "NetworkManager is not running" > but maybe this is another issue and your patch did solve the devio.c problem. > Unfortunately I cannot use the 4.7.2 kernel with ubsan and asan because > I need the networkmanager running, as it is doing now on kernel version 4.6.6 The NetworkManager problem does look like something completely separate. So thanks for testing the patch, and I will submit it soon. Alan Stern ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-08-23 18:58 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAFQ=mRQeV_UHYuU20ppHG6L=mNcr_cKxBMMM731XfWeoEO-L=g@mail.gmail.com>
2016-08-21 10:46 ` UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25 Jiri Slaby
2016-08-22 17:43 ` Alan Stern
2016-08-22 20:21 ` Bjørn Mork
2016-08-22 20:40 ` Alan Stern
2016-08-22 20:57 ` Bjørn Mork
2016-08-22 21:06 ` Alan Stern
2016-08-22 21:45 ` Vittorio Zecca
2016-08-23 14:55 ` Alan Stern
2016-08-23 15:47 ` Vittorio Zecca
2016-08-23 18:58 ` Alan Stern
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).