usb/net/qmi_wwan: divide error in qmi_wwan_probe/usbnet_probe

625 views
Skip to first unread message

Andrey Konovalov

unread,
Nov 6, 2017, 8:27:27 AM11/6/17
to Oliver Neukum, netdev, USB list, LKML, Bjørn Mork, Dmitry Vyukov, Kostya Serebryany, syzkaller
Hi!

I've got the following report while fuzzing the kernel with syzkaller.

On commit 39dae59d66acd86d1de24294bd2f343fd5e7a625 (4.14-rc8).

qmi_wwan 1-1:0.4: cdc-wdm0: USB WDM device
divide error: 0000 [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc8-44453-g1fdc1a82c34f #56
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: ffff88006bef5c00 task.stack: ffff88006bf60000
RIP: 0010:usbnet_update_max_qlen+0x24d/0x390 drivers/net/usb/usbnet.c:355
RSP: 0018:ffff88006bf67508 EFLAGS: 00010246
RAX: 00000000000163c8 RBX: ffff8800621fce40 RCX: ffff8800621fcf34
RDX: 0000000000000000 RSI: ffffffff837ecb7a RDI: ffff8800621fcf34
RBP: ffff88006bf67520 R08: ffff88006bef5c00 R09: ffffed000c43f881
R10: ffffed000c43f880 R11: ffff8800621fc406 R12: 0000000000000003
R13: ffffffff85c71de0 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88006ca00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe9c0d6dac CR3: 00000000614f4000 CR4: 00000000000006f0
Call Trace:
usbnet_probe+0x18b5/0x2790 drivers/net/usb/usbnet.c:1783
qmi_wwan_probe+0x133/0x220 drivers/net/usb/qmi_wwan.c:1338
usb_probe_interface+0x324/0x940 drivers/usb/core/driver.c:361
really_probe drivers/base/dd.c:413
driver_probe_device+0x522/0x740 drivers/base/dd.c:557
__device_attach_driver+0x25d/0x2d0 drivers/base/dd.c:653
bus_for_each_drv+0xff/0x160 drivers/base/bus.c:463
__device_attach+0x1a8/0x2a0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1fc/0x2a0 drivers/base/bus.c:523
device_add+0xc27/0x15a0 drivers/base/core.c:1835
usb_set_configuration+0xd4f/0x17a0 drivers/usb/core/message.c:1932
generic_probe+0xbb/0x120 drivers/usb/core/generic.c:174
usb_probe_device+0xab/0x100 drivers/usb/core/driver.c:266
really_probe drivers/base/dd.c:413
driver_probe_device+0x522/0x740 drivers/base/dd.c:557
__device_attach_driver+0x25d/0x2d0 drivers/base/dd.c:653
bus_for_each_drv+0xff/0x160 drivers/base/bus.c:463
__device_attach+0x1a8/0x2a0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1fc/0x2a0 drivers/base/bus.c:523
device_add+0xc27/0x15a0 drivers/base/core.c:1835
usb_new_device+0x7fa/0x1090 drivers/usb/core/hub.c:2538
hub_port_connect drivers/usb/core/hub.c:4987
hub_port_connect_change drivers/usb/core/hub.c:5093
port_event drivers/usb/core/hub.c:5199
hub_event_impl+0x17b8/0x3440 drivers/usb/core/hub.c:5311
hub_event+0x38/0x50 drivers/usb/core/hub.c:5209
process_one_work+0x925/0x15d0 kernel/workqueue.c:2113
worker_thread+0xef/0x10d0 kernel/workqueue.c:2247
kthread+0x346/0x410 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:432
Code: b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f
85 46 01 00 00 48 8d bb f4 00 00 00 31 d2 b8 c8 63 01 00 48 89 f9 <48>
f7 b3 b0 01 00 00 48 ba 00 00 00 00 00 fc ff df 48 c1 e9 03
RIP: usbnet_update_max_qlen+0x24d/0x390 RSP: ffff88006bf67508
---[ end trace 834034903d6f2b37 ]---

Bjørn Mork

unread,
Nov 6, 2017, 9:06:20 AM11/6/17
to Andrey Konovalov, Oliver Neukum, netdev, USB list, LKML, Dmitry Vyukov, Kostya Serebryany, syzkaller
Andrey Konovalov <andre...@google.com> writes:

> Hi!
>
> I've got the following report while fuzzing the kernel with syzkaller.

Thanks. It would have helped a lot of you said *what* you were fuzzing,
though.... But based on where the bug is, I assume it is USB
descriptors?


> On commit 39dae59d66acd86d1de24294bd2f343fd5e7a625 (4.14-rc8).
>
> qmi_wwan 1-1:0.4: cdc-wdm0: USB WDM device
> divide error: 0000 [#1] PREEMPT SMP KASAN
> Modules linked in:
> CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc8-44453-g1fdc1a82c34f #56
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> task: ffff88006bef5c00 task.stack: ffff88006bf60000
> RIP: 0010:usbnet_update_max_qlen+0x24d/0x390 drivers/net/usb/usbnet.c:355
> RSP: 0018:ffff88006bf67508 EFLAGS: 00010246
> RAX: 00000000000163c8 RBX: ffff8800621fce40 RCX: ffff8800621fcf34
> RDX: 0000000000000000 RSI: ffffffff837ecb7a RDI: ffff8800621fcf34
> RBP: ffff88006bf67520 R08: ffff88006bef5c00 R09: ffffed000c43f881
> R10: ffffed000c43f880 R11: ffff8800621fc406 R12: 0000000000000003
> R13: ffffffff85c71de0 R14: 0000000000000000 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffff88006ca00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007ffe9c0d6dac CR3: 00000000614f4000 CR4: 00000000000006f0
> Call Trace:
> usbnet_probe+0x18b5/0x2790 drivers/net/usb/usbnet.c:1783
> qmi_wwan_probe+0x133/0x220 drivers/net/usb/qmi_wwan.c:1338

So, looking over this again and again, the only obviously risky division
I can see is the usbnet_update_max_qlen() call where we divide on both
dev->rx_urb_size and dev->hard_mtu.

I don't think dev->rx_urb_size can be 0 unless dev->hard_mtu is 0. But
the latter is possible, and this is a bug. In qmi_wwan_bind(), which is
called by usbnet_probe() prior to the usbnet_update_max_qlen() call, we
do

if (cdc_ether) {
dev->hard_mtu = le16_to_cpu(cdc_ether->wMaxSegmentSize);
usbnet_get_ethernet_addr(dev, cdc_ether->iMACAddress);
}

which will be fatal if cdc_ether->wMaxSegmentSize is 0. I assume that
is what your fuzzer did? Fix coming up RSN. Thanks a lot for pointing
this out.


Bjørn

Andrey Konovalov

unread,
Nov 6, 2017, 10:19:59 AM11/6/17
to Bjørn Mork, Oliver Neukum, netdev, USB list, LKML, Dmitry Vyukov, Kostya Serebryany, syzkaller
On Mon, Nov 6, 2017 at 3:06 PM, Bjørn Mork <bj...@mork.no> wrote:
> Andrey Konovalov <andre...@google.com> writes:
>
>> Hi!
>>
>> I've got the following report while fuzzing the kernel with syzkaller.
>
> Thanks. It would have helped a lot of you said *what* you were fuzzing,
> though.... But based on where the bug is, I assume it is USB
> descriptors?

Yes, I was connecting USB devices with random descriptors. I though
it's obvious from the stack trace, but I'll include that in the
following reports. Thanks!
I don't see the crash with your patches. Thanks for a quick fix!

>
>
> Bjørn
Reply all
Reply to author
Forward
0 new messages