Hello,
syzbot found the following crash on:
HEAD commit: 9939f56e usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=1615a669a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=df134eda130bb43a
dashboard link: https://syzkaller.appspot.com/bug?extid=b68605d7fadd21510de1
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10630af6a00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1127da69a00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: [email protected]
usb 1-1: new high-speed USB device number 2 using dummy_hcd
usb 1-1: Using ep0 maxpacket: 8
usb 1-1: New USB device found, idVendor=12d1, idProduct=14f1,
bcdDevice=d4.d9
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
==================================================================
BUG: KASAN: global-out-of-bounds in qmi_wwan_probe+0x342/0x360
drivers/net/usb/qmi_wwan.c:1417
Read of size 8 at addr ffffffff8618c140 by task kworker/1:1/22
CPU: 1 PID: 22 Comm: kworker/1:1 Not tainted 5.2.0-rc5+ #11
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
print_address_description+0x67/0x231 mm/kasan/report.c:188
__kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
kasan_report+0xe/0x20 mm/kasan/common.c:614
qmi_wwan_probe+0x342/0x360 drivers/net/usb/qmi_wwan.c:1417
usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
really_probe+0x281/0x660 drivers/base/dd.c:509
driver_probe_device+0x104/0x210 drivers/base/dd.c:670
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
syzbot <[email protected]> writes:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 9939f56e usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=1615a669a00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=df134eda130bb43a
> dashboard link: https://syzkaller.appspot.com/bug?extid=b68605d7fadd21510de1
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10630af6a00000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1127da69a00000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: [email protected]
>
> usb 1-1: new high-speed USB device number 2 using dummy_hcd
> usb 1-1: Using ep0 maxpacket: 8
> usb 1-1: New USB device found, idVendor=12d1, idProduct=14f1,
> bcdDevice=d4.d9
> usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> usb 1-1: config 0 descriptor??
> ==================================================================
> BUG: KASAN: global-out-of-bounds in qmi_wwan_probe+0x342/0x360
> drivers/net/usb/qmi_wwan.c:1417
> Read of size 8 at addr ffffffff8618c140 by task kworker/1:1/22
>
> CPU: 1 PID: 22 Comm: kworker/1:1 Not tainted 5.2.0-rc5+ #11
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
> Workqueue: usb_hub_wq hub_event
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0xca/0x13e lib/dump_stack.c:113
> print_address_description+0x67/0x231 mm/kasan/report.c:188
> __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
> kasan_report+0xe/0x20 mm/kasan/common.c:614
> qmi_wwan_probe+0x342/0x360 drivers/net/usb/qmi_wwan.c:1417
> usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
> really_probe+0x281/0x660 drivers/base/dd.c:509
> driver_probe_device+0x104/0x210 drivers/base/dd.c:670
> __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777
> bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
>
Hello Kristian!
I need some help understanding this... IIUC syzbot is claiming an
out-of-bounds access at line 1417 in v5.2-rc5. Or whatever - I'm having
a hard time deciphering what kernel version the bot is actually
testing. The claimed HEAD is not a kernel commit. At least not in my
kernel...
But if this is correct, then it points to the info->data access you
recently added:
822e44b45eb99 (Kristian Evensen 2019-03-02 13:32:26 +0100 1409) /* Several Quectel modems supports dynamic interface configuration, so
7c5cca3588545 (Kristian Evensen 2018-09-08 13:50:48 +0200 1410) * we need to match on class/subclass/protocol. These values are
7c5cca3588545 (Kristian Evensen 2018-09-08 13:50:48 +0200 1411) * identical for the diagnostic- and QMI-interface, but bNumEndpoints is
7c5cca3588545 (Kristian Evensen 2018-09-08 13:50:48 +0200 1412) * different. Ignore the current interface if the number of endpoints
e4bf63482c309 (Kristian Evensen 2019-04-07 15:39:09 +0200 1413) * equals the number for the diag interface (two).
7c5cca3588545 (Kristian Evensen 2018-09-08 13:50:48 +0200 1414) */
e4bf63482c309 (Kristian Evensen 2019-04-07 15:39:09 +0200 1415) info = (void *)&id->driver_info;
e4bf63482c309 (Kristian Evensen 2019-04-07 15:39:09 +0200 1416)
e4bf63482c309 (Kristian Evensen 2019-04-07 15:39:09 +0200 1417) if (info->data & QMI_WWAN_QUIRK_QUECTEL_DYNCFG) {
e4bf63482c309 (Kristian Evensen 2019-04-07 15:39:09 +0200 1418) if (desc->bNumEndpoints == 2)
e4bf63482c309 (Kristian Evensen 2019-04-07 15:39:09 +0200 1419) return -ENODEV;
e4bf63482c309 (Kristian Evensen 2019-04-07 15:39:09 +0200 1420) }
I must be blind. I cannot see how this could end up failing.
id->driver_info is always set to one of qmi_wwan_info,
qmi_wwan_info_quirk_dtr or qmi_wwan_info_quirk_quectel_dyncfg at this
point. How does that end up out-of-bounds?
Bjørn
On Mon, Jun 24, 2019 at 2:59 PM Bjørn Mork <[email protected]> wrote:
>
> syzbot <[email protected]> writes:
>
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 9939f56e usb-fuzzer: main usb gadget fuzzer driver
> > git tree: https://github.com/google/kasan.git usb-fuzzer
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1615a669a00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=df134eda130bb43a
> > dashboard link: https://syzkaller.appspot.com/bug?extid=b68605d7fadd21510de1
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10630af6a00000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1127da69a00000
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: [email protected]
> >
> > usb 1-1: new high-speed USB device number 2 using dummy_hcd
> > usb 1-1: Using ep0 maxpacket: 8
> > usb 1-1: New USB device found, idVendor=12d1, idProduct=14f1,
> > bcdDevice=d4.d9
> > usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> > usb 1-1: config 0 descriptor??
> > ==================================================================
> > BUG: KASAN: global-out-of-bounds in qmi_wwan_probe+0x342/0x360
> > drivers/net/usb/qmi_wwan.c:1417
> > Read of size 8 at addr ffffffff8618c140 by task kworker/1:1/22
> >
> > CPU: 1 PID: 22 Comm: kworker/1:1 Not tainted 5.2.0-rc5+ #11
> > Hardware name: Google Google Compute Engine/Google Compute Engine,
> > BIOS Google 01/01/2011
> > Workqueue: usb_hub_wq hub_event
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0xca/0x13e lib/dump_stack.c:113
> > print_address_description+0x67/0x231 mm/kasan/report.c:188
> > __kasan_report.cold+0x1a/0x32 mm/kasan/report.c:317
> > kasan_report+0xe/0x20 mm/kasan/common.c:614
> > qmi_wwan_probe+0x342/0x360 drivers/net/usb/qmi_wwan.c:1417
> > usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
> > really_probe+0x281/0x660 drivers/base/dd.c:509
> > driver_probe_device+0x104/0x210 drivers/base/dd.c:670
> > __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777
> > bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
> >
>
> Hello Kristian!
>
> I need some help understanding this... IIUC syzbot is claiming an
> out-of-bounds access at line 1417 in v5.2-rc5. Or whatever - I'm having
> a hard time deciphering what kernel version the bot is actually
> testing. The claimed HEAD is not a kernel commit. At least not in my
> kernel...
The bot currently tests this tree:
https://github.com/google/kasan/tree/usb-fuzzer, which is essentially
5.2-rc5.
>
>
> But if this is correct, then it points to the info->data access you
> recently added:
>
> 822e44b45eb99 (Kristian Evensen 2019-03-02 13:32:26 +0100 1409) /* Several Quectel modems supports dynamic interface configuration, so
> 7c5cca3588545 (Kristian Evensen 2018-09-08 13:50:48 +0200 1410) * we need to match on class/subclass/protocol. These values are
> 7c5cca3588545 (Kristian Evensen 2018-09-08 13:50:48 +0200 1411) * identical for the diagnostic- and QMI-interface, but bNumEndpoints is
> 7c5cca3588545 (Kristian Evensen 2018-09-08 13:50:48 +0200 1412) * different. Ignore the current interface if the number of endpoints
> e4bf63482c309 (Kristian Evensen 2019-04-07 15:39:09 +0200 1413) * equals the number for the diag interface (two).
> 7c5cca3588545 (Kristian Evensen 2018-09-08 13:50:48 +0200 1414) */
> e4bf63482c309 (Kristian Evensen 2019-04-07 15:39:09 +0200 1415) info = (void *)&id->driver_info;
> e4bf63482c309 (Kristian Evensen 2019-04-07 15:39:09 +0200 1416)
> e4bf63482c309 (Kristian Evensen 2019-04-07 15:39:09 +0200 1417) if (info->data & QMI_WWAN_QUIRK_QUECTEL_DYNCFG) {
> e4bf63482c309 (Kristian Evensen 2019-04-07 15:39:09 +0200 1418) if (desc->bNumEndpoints == 2)
> e4bf63482c309 (Kristian Evensen 2019-04-07 15:39:09 +0200 1419) return -ENODEV;
> e4bf63482c309 (Kristian Evensen 2019-04-07 15:39:09 +0200 1420) }
>
>
> I must be blind. I cannot see how this could end up failing.
> id->driver_info is always set to one of qmi_wwan_info,
> qmi_wwan_info_quirk_dtr or qmi_wwan_info_quirk_quectel_dyncfg at this
> point. How does that end up out-of-bounds?
I've run the reproducer locally and checked the addresses. The
structures that you mentioned are at:
gef> p &qmi_wwan_info
$1 = (const struct driver_info *) 0xffffffff85d32e80 <qmi_wwan_info>
gef> p &qmi_wwan_info_quirk_dtr
$2 = (const struct driver_info *) 0xffffffff85d32dc0 <qmi_wwan_info_quirk_dtr>
gef> p &qmi_wwan_info_quirk_quectel_dyncfg
$3 = (const struct driver_info *) 0xffffffff85d32d00
<qmi_wwan_info_quirk_quectel_dyncfg>
And the bad access for me happens on address 0xffffffff85d32ce0, so it
seems that driver_info somehow ended up lying below
qmi_wwan_info_quirk_quectel_dyncfg.
gef> x/6gx 0xffffffff85d32ce0
0xffffffff85d32ce0: 0x0000000000000000 0x0000000000000000
0xffffffff85d32cf0: 0x0000000000000000 0x0000000000000000
0xffffffff85d32d00 <qmi_wwan_info_quirk_quectel_dyncfg>:
0xffffffff85d32cc0 0x0000000000000600
>
>
>
> Bjørn
Hillf Danton <[email protected]> writes:
> and wonder if the following works.
>
> - info = (void *)&id->driver_info;
> + info = (void *)id->driver_info;
Doh! Right you are. Thanks to both you and Andrey for quick and good
help.
We obviously have some bad code patterns here, since this apparently
worked for Kristian by pure luck.
Bjørn
Hi,
On Mon, Jun 24, 2019 at 6:26 PM Bjørn Mork <[email protected]> wrote:
> Doh! Right you are. Thanks to both you and Andrey for quick and good
> help.
>
> We obviously have some bad code patterns here, since this apparently
> worked for Kristian by pure luck.
Thanks a lot to everyone for spotting and fixing my mistake, and sorry
for not replying earlier. The patch from Bjørn is probably a candidate
for stable as well. I don't remember exactly when the quirk was
accepted in the kernel, but I recently submitted and got the quirk
accepted into 4.14.
BR,
Kristian