Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25

Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25

[Jiri Slaby]

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

Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25

[Alan Stern]

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

Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25

[Bjørn Mork]

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

Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25

[Alan Stern]

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

Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25

[Bjørn Mork]

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

Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25

[Alan Stern]

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

Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25

[Vittorio Zecca]

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.

Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25

[Alan Stern]

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++) {

Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25

[Vittorio Zecca]

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

Re: UBSAN: Undefined behaviour in linux-4.7.2/drivers/usb/core/devio.c:1713:25

[Alan Stern]

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