KASAN: global-out-of-bounds Read in qmi_wwan_probe

[syzbot]

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: syzbot+b68605...@syzkaller.appspotmail.com

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 syzk...@googlegroups.com.

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

[Bjørn Mork]

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

[Andrey Konovalov]

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

[Kristian Evensen]

Hi,

On Mon, Jun 24, 2019 at 6:26 PM Bjørn Mork <bj...@mork.no> 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