linux-kernel - Re: usb/net/qmi_wwan: divide error in qmi_wwan_probe/usbnet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 6 Nov 2017 16:19:58 +0100
From:   Andrey Konovalov <andreyknvl@...gle.com>
To:     Bjørn Mork <bjorn@...k.no>
Cc:     Oliver Neukum <oneukum@...e.com>, netdev <netdev@...r.kernel.org>,
        USB list <linux-usb@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Kostya Serebryany <kcc@...gle.com>,
        syzkaller <syzkaller@...glegroups.com>
Subject: Re: usb/net/qmi_wwan: divide error in qmi_wwan_probe/usbnet_probe

On Mon, Nov 6, 2017 at 3:06 PM, Bjørn Mork <bjorn@...k.no> wrote:
> Andrey Konovalov <andreyknvl@...gle.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!

>
>
>> 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.

I don't see the crash with your patches. Thanks for a quick fix!

>
>
> Bjørn