* KASAN: use-after-free Read in p54u_load_firmware_cb
@ 2019-05-06 11:16 syzbot
2019-05-13 10:23 ` syzbot
0 siblings, 1 reply; 21+ messages in thread
From: syzbot @ 2019-05-06 11:16 UTC (permalink / raw)
To: andreyknvl, chunkeey, davem, kvalo, linux-kernel, linux-usb,
linux-wireless, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 43151d6c 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=142b312ca00000
kernel config: https://syzkaller.appspot.com/x/.config?x=4183eeef650d1234
dashboard link: https://syzkaller.appspot.com/bug?extid=200d4bb11b23d929335f
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com
usb 4-1: Direct firmware load for isl3887usb failed with error -2
usb 4-1: Firmware not found.
==================================================================
BUG: KASAN: use-after-free in p54u_load_firmware_cb.cold+0x97/0x13a
drivers/net/wireless/intersil/p54/p54usb.c:936
Read of size 8 at addr ffff888098bf3588 by task kworker/0:1/12
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.1.0-rc3-319004-g43151d6 #6
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events request_firmware_work_func
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xe8/0x16e lib/dump_stack.c:113
print_address_description+0x6c/0x236 mm/kasan/report.c:187
kasan_report.cold+0x1a/0x3c mm/kasan/report.c:317
p54u_load_firmware_cb.cold+0x97/0x13a
drivers/net/wireless/intersil/p54/p54usb.c:936
request_firmware_work_func+0x12d/0x249
drivers/base/firmware_loader/main.c:785
process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
kthread+0x313/0x420 kernel/kthread.c:253
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
The buggy address belongs to the page:
page:ffffea000262fcc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0xfff00000000000()
raw: 00fff00000000000 0000000000000000 ffffffff02620101 0000000000000000
raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888098bf3480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff888098bf3500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ffff888098bf3580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff888098bf3600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff888098bf3680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
==================================================================
---
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 syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: KASAN: use-after-free Read in p54u_load_firmware_cb 2019-05-06 11:16 KASAN: use-after-free Read in p54u_load_firmware_cb syzbot @ 2019-05-13 10:23 ` syzbot 2019-05-13 13:28 ` Oliver Neukum 0 siblings, 1 reply; 21+ messages in thread From: syzbot @ 2019-05-13 10:23 UTC (permalink / raw) To: andreyknvl, chunkeey, davem, kvalo, linux-kernel, linux-usb, linux-wireless, netdev, syzkaller-bugs syzbot has found a reproducer for the following crash on: HEAD commit: 43151d6c 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=16b64110a00000 kernel config: https://syzkaller.appspot.com/x/.config?x=4183eeef650d1234 dashboard link: https://syzkaller.appspot.com/bug?extid=200d4bb11b23d929335f compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1634c900a00000 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com usb 1-1: config 0 descriptor?? usb 1-1: reset high-speed USB device number 2 using dummy_hcd usb 1-1: device descriptor read/64, error -71 usb 1-1: Using ep0 maxpacket: 8 usb 1-1: Loading firmware file isl3887usb usb 1-1: Direct firmware load for isl3887usb failed with error -2 usb 1-1: Firmware not found. ================================================================== BUG: KASAN: use-after-free in p54u_load_firmware_cb.cold+0x97/0x13a drivers/net/wireless/intersil/p54/p54usb.c:936 Read of size 8 at addr ffff88809803f588 by task kworker/1:0/17 CPU: 1 PID: 17 Comm: kworker/1:0 Not tainted 5.1.0-rc3-319004-g43151d6 #6 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events request_firmware_work_func Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe8/0x16e lib/dump_stack.c:113 print_address_description+0x6c/0x236 mm/kasan/report.c:187 kasan_report.cold+0x1a/0x3c mm/kasan/report.c:317 p54u_load_firmware_cb.cold+0x97/0x13a drivers/net/wireless/intersil/p54/p54usb.c:936 request_firmware_work_func+0x12d/0x249 drivers/base/firmware_loader/main.c:785 process_one_work+0x90f/0x1580 kernel/workqueue.c:2269 worker_thread+0x9b/0xe20 kernel/workqueue.c:2415 kthread+0x313/0x420 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Allocated by task 0: (stack is not available) Freed by task 0: (stack is not available) The buggy address belongs to the object at ffff88809803f180 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 8 bytes to the right of 1024-byte region [ffff88809803f180, ffff88809803f580) The buggy address belongs to the page: page:ffffea0002600f00 count:1 mapcount:0 mapping:ffff88812c3f4a00 index:0x0 compound_mapcount: 0 flags: 0xfff00000010200(slab|head) raw: 00fff00000010200 dead000000000100 dead000000000200 ffff88812c3f4a00 raw: 0000000000000000 00000000800e000e 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88809803f480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88809803f500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ffff88809803f580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88809803f600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88809803f680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb 2019-05-13 10:23 ` syzbot @ 2019-05-13 13:28 ` Oliver Neukum 2019-05-17 19:21 ` Christian Lamparter 0 siblings, 1 reply; 21+ messages in thread From: Oliver Neukum @ 2019-05-13 13:28 UTC (permalink / raw) To: syzbot, kvalo, davem, andreyknvl, syzkaller-bugs, chunkeey, linux-kernel, linux-usb, linux-wireless, netdev Cc: Michael Wu On Mo, 2019-05-13 at 03:23 -0700, syzbot wrote: > syzbot has found a reproducer for the following crash on: > > HEAD commit: 43151d6c 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=16b64110a00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=4183eeef650d1234 > dashboard link: https://syzkaller.appspot.com/bug?extid=200d4bb11b23d929335f > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1634c900a00000 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com > > usb 1-1: config 0 descriptor?? > usb 1-1: reset high-speed USB device number 2 using dummy_hcd > usb 1-1: device descriptor read/64, error -71 > usb 1-1: Using ep0 maxpacket: 8 > usb 1-1: Loading firmware file isl3887usb > usb 1-1: Direct firmware load for isl3887usb failed with error -2 > usb 1-1: Firmware not found. > ================================================================== > BUG: KASAN: use-after-free in p54u_load_firmware_cb.cold+0x97/0x13a > drivers/net/wireless/intersil/p54/p54usb.c:936 > Read of size 8 at addr ffff88809803f588 by task kworker/1:0/17 Hi, it looks to me as if refcounting is broken. You should have a usb_put_dev() in p54u_load_firmware_cb() or in p54u_disconnect(), but not both. Regards Oliver ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb 2019-05-13 13:28 ` Oliver Neukum @ 2019-05-17 19:21 ` Christian Lamparter 2019-05-17 20:46 ` Alan Stern 2019-05-20 14:44 ` [PATCH] network: wireless: p54u: Fix race between disconnect and firmware loading Alan Stern 0 siblings, 2 replies; 21+ messages in thread From: Christian Lamparter @ 2019-05-17 19:21 UTC (permalink / raw) To: Oliver Neukum Cc: syzbot, kvalo, davem, andreyknvl, syzkaller-bugs, chunkeey, linux-kernel, linux-usb, linux-wireless, netdev, Michael Wu On Monday, May 13, 2019 3:28:30 PM CEST Oliver Neukum wrote: > On Mo, 2019-05-13 at 03:23 -0700, syzbot wrote: > > syzbot has found a reproducer for the following crash on: > > > > HEAD commit: 43151d6c 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=16b64110a00000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=4183eeef650d1234 > > dashboard link: https://syzkaller.appspot.com/bug?extid=200d4bb11b23d929335f > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1634c900a00000 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com > > > > usb 1-1: config 0 descriptor?? > > usb 1-1: reset high-speed USB device number 2 using dummy_hcd > > usb 1-1: device descriptor read/64, error -71 > > usb 1-1: Using ep0 maxpacket: 8 > > usb 1-1: Loading firmware file isl3887usb > > usb 1-1: Direct firmware load for isl3887usb failed with error -2 > > usb 1-1: Firmware not found. > > ================================================================== > > BUG: KASAN: use-after-free in p54u_load_firmware_cb.cold+0x97/0x13a > > drivers/net/wireless/intersil/p54/p54usb.c:936 > > Read of size 8 at addr ffff88809803f588 by task kworker/1:0/17 > > Hi, > > it looks to me as if refcounting is broken. > You should have a usb_put_dev() in p54u_load_firmware_cb() or in > p54u_disconnect(), but not both. There's more to that refcounting that meets the eye. Do you see that request_firmware_nowait() in the driver? That's the async firmware request call that get's completed by the p54u_load_firmware_cb() So what's happening here is that the driver has to be protected against rmmod when the driver is waiting for request_firmware_nowait to "finally" callback, which depending on the system can be up to 60 seconds. Now, what seems to be odd is that it's at line 936 > > BUG: KASAN: use-after-free in p54u_load_firmware_cb.cold+0x97/0x13a > > drivers/net/wireless/intersil/p54/p54usb.c:936 because if you put it in context: | |static void p54u_load_firmware_cb(const struct firmware *firmware, | void *context) |{ | struct p54u_priv *priv = context; | struct usb_device *udev = priv->udev; | int err; | | complete(&priv->fw_wait_load); | if (firmware) { | priv->fw = firmware; | err = p54u_start_ops(priv); | } else { | err = -ENOENT; | dev_err(&udev->dev, "Firmware not found.\n"); | } | | if (err) { |>> >> struct device *parent = priv->udev->dev.parent; <<<<-- 936 is here | | dev_err(&udev->dev, "failed to initialize device (%d)\n", err); | | if (parent) | device_lock(parent); | | device_release_driver(&udev->dev); | /* | * At this point p54u_disconnect has already freed | * the "priv" context. Do not use it anymore! | */ | priv = NULL; | | if (parent) | device_unlock(parent); | } | | usb_put_dev(udev); |} it seems very out of place, because at that line the device is still bound to the driver! Only with device_release_driver in line 942, I could see that something woulb be aray... !BUT! that's why we do have the extra usb_get_dev(udev) in p54u_load_firmware() so we can do the usb_put_dev(udev) in line 953 to ensure that nothing (like the rmmod I talked above) will interfere until everything is done. I've no idea what's wrong here, is gcc 9.0 aggressivly reording the put? Or is something else going on with the sanitizers? Because this report does look dogdy there! (Note: p54usb has !strategic! dev_err/infos in place right around the usb_get_dev/usb_put_dev so we can sort of tell the refvalue of the udev and it all seems to be correct from what I can gleam) Regards, Christian ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb 2019-05-17 19:21 ` Christian Lamparter @ 2019-05-17 20:46 ` Alan Stern 2019-05-17 21:01 ` syzbot 2019-05-20 14:44 ` [PATCH] network: wireless: p54u: Fix race between disconnect and firmware loading Alan Stern 1 sibling, 1 reply; 21+ messages in thread From: Alan Stern @ 2019-05-17 20:46 UTC (permalink / raw) To: Christian Lamparter Cc: Oliver Neukum, syzbot, kvalo, davem, andreyknvl, syzkaller-bugs, chunkeey, linux-kernel, linux-usb, linux-wireless, netdev, Michael Wu On Fri, 17 May 2019, Christian Lamparter wrote: > On Monday, May 13, 2019 3:28:30 PM CEST Oliver Neukum wrote: > > On Mo, 2019-05-13 at 03:23 -0700, syzbot wrote: > > > syzbot has found a reproducer for the following crash on: > > > > > > HEAD commit: 43151d6c 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=16b64110a00000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=4183eeef650d1234 > > > dashboard link: https://syzkaller.appspot.com/bug?extid=200d4bb11b23d929335f > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1634c900a00000 > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > Reported-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com > > > > > > usb 1-1: config 0 descriptor?? > > > usb 1-1: reset high-speed USB device number 2 using dummy_hcd > > > usb 1-1: device descriptor read/64, error -71 > > > usb 1-1: Using ep0 maxpacket: 8 > > > usb 1-1: Loading firmware file isl3887usb > > > usb 1-1: Direct firmware load for isl3887usb failed with error -2 > > > usb 1-1: Firmware not found. > > > ================================================================== > > > BUG: KASAN: use-after-free in p54u_load_firmware_cb.cold+0x97/0x13a > > > drivers/net/wireless/intersil/p54/p54usb.c:936 > > > Read of size 8 at addr ffff88809803f588 by task kworker/1:0/17 > > > > Hi, > > > > it looks to me as if refcounting is broken. > > You should have a usb_put_dev() in p54u_load_firmware_cb() or in > > p54u_disconnect(), but not both. > > There's more to that refcounting that meets the eye. Do you see that > request_firmware_nowait() in the driver? That's the async firmware > request call that get's completed by the p54u_load_firmware_cb() > So what's happening here is that the driver has to be protected > against rmmod when the driver is waiting for request_firmware_nowait > to "finally" callback, which depending on the system can be up to > 60 seconds. > > Now, what seems to be odd is that it's at line 936 > > > BUG: KASAN: use-after-free in p54u_load_firmware_cb.cold+0x97/0x13a > > > drivers/net/wireless/intersil/p54/p54usb.c:936 > > because if you put it in context: > > | > |static void p54u_load_firmware_cb(const struct firmware *firmware, > | void *context) > |{ > | struct p54u_priv *priv = context; > | struct usb_device *udev = priv->udev; > | int err; > | > | complete(&priv->fw_wait_load); > | if (firmware) { > | priv->fw = firmware; > | err = p54u_start_ops(priv); > | } else { > | err = -ENOENT; > | dev_err(&udev->dev, "Firmware not found.\n"); > | } > | > | if (err) { > |>> >> struct device *parent = priv->udev->dev.parent; <<<<-- 936 is here > | > | dev_err(&udev->dev, "failed to initialize device (%d)\n", err); > | > | if (parent) > | device_lock(parent); > | > | device_release_driver(&udev->dev); > | /* > | * At this point p54u_disconnect has already freed > | * the "priv" context. Do not use it anymore! > | */ > | priv = NULL; > | > | if (parent) > | device_unlock(parent); > | } > | > | usb_put_dev(udev); > |} > > it seems very out of place, because at that line the device is still bound to > the driver! Only with device_release_driver in line 942, I could see that > something woulb be aray... !BUT! that's why we do have the extra > usb_get_dev(udev) in p54u_load_firmware() so we can do the usb_put_dev(udev) in > line 953 to ensure that nothing (like the rmmod I talked above) will interfere > until everything is done. > > I've no idea what's wrong here, is gcc 9.0 aggressivly reording the put? Or is > something else going on with the sanitizers? Because this report does look > dogdy there! > > (Note: p54usb has !strategic! dev_err/infos in place right around the > usb_get_dev/usb_put_dev so we can sort of tell the refvalue of the udev > and it all seems to be correct from what I can gleam) I agree; it doesn't seem to make sense. The nice thing about syzbot, though, is you can ask it to run a debugging test for you. Let's start by making sure that the faulty address really is &udev->dev.parent. Alan #syz test: https://github.com/google/kasan.git usb-fuzzer drivers/net/wireless/intersil/p54/p54usb.c | 3 +++ 1 file changed, 3 insertions(+) Index: usb-devel/drivers/net/wireless/intersil/p54/p54usb.c =================================================================== --- usb-devel.orig/drivers/net/wireless/intersil/p54/p54usb.c +++ usb-devel/drivers/net/wireless/intersil/p54/p54usb.c @@ -923,6 +923,7 @@ static void p54u_load_firmware_cb(const struct usb_device *udev = priv->udev; int err; + pr_info("%s: priv->udev = %px\n", __func__, udev); complete(&priv->fw_wait_load); if (firmware) { priv->fw = firmware; @@ -969,6 +970,8 @@ static int p54u_load_firmware(struct iee if (i < 0) return i; + dev_info(udev, "%s: udev @ %px, dev.parent @ %px\n", + __func__, udev, &udev->dev.parent); dev_info(&priv->udev->dev, "Loading firmware file %s\n", p54u_fwlist[i].fw); ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb 2019-05-17 20:46 ` Alan Stern @ 2019-05-17 21:01 ` syzbot 2019-05-18 15:13 ` Alan Stern 0 siblings, 1 reply; 21+ messages in thread From: syzbot @ 2019-05-17 21:01 UTC (permalink / raw) To: andreyknvl, chunkeey, chunkeey, davem, flamingice, kvalo, linux-kernel, linux-usb, linux-wireless, netdev, oneukum, stern, syzkaller-bugs Hello, syzbot tried to test the proposed patch but build/boot failed: | ipr_init_dump_entry_hdr(&driver_dump->location_entry.hdr); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CC drivers/gpu/drm/nouveau/nvkm/engine/disp/ovlygk104.o CC drivers/scsi/xen-scsifront.o drivers/scsi/ipr.c: In function ‘ipr_build_ioadl’: drivers/scsi/ipr.c:6017:11: warning: taking address of packed member of ‘struct ipr_ioarcb_add_data’ may result in an unaligned pointer value [-Waddress-of-packed-member] 6017 | ioadl = ioarcb->u.add_data.u.ioadl; | ^~~~~~ drivers/scsi/ipr.c: In function ‘ipr_check_term_power’: drivers/scsi/ipr.c:7452:8: warning: taking address of packed member of ‘struct ipr_mode_page28’ may result in an unaligned pointer value [-Waddress-of-packed-member] 7452 | bus = mode_page->bus; | ^~~~~~~~~ drivers/scsi/ipr.c: In function ‘ipr_modify_ioafp_mode_page_28’: drivers/scsi/ipr.c:7514:20: warning: taking address of packed member of ‘struct ipr_mode_page28’ may result in an unaligned pointer value [-Waddress-of-packed-member] 7514 | for (i = 0, bus = mode_page->bus; | ^~~~~~~~~ CC drivers/scsi/storvsc_drv.o CC drivers/scsi/wd719x.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/ovlygp102.o CC drivers/scsi/st.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.o CC drivers/scsi/osst.o drivers/scsi/storvsc_drv.c: In function ‘storvsc_on_channel_callback’: drivers/scsi/storvsc_drv.c:1173:24: warning: taking address of packed member of ‘struct vmpacket_descriptor’ may result in an unaligned pointer value [-Waddress-of-packed-member] 1173 | ((unsigned long)desc->trans_id); | ~~~~^~~~~~~~~~ CC drivers/gpu/drm/nouveau/nvkm/engine/disp/wndwgv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/piocnv50.o CC drivers/scsi/sd.o CC drivers/scsi/sd_dif.o CC drivers/scsi/sd_zbc.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/piocgf119.o CC drivers/scsi/sr.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/cursnv50.o CC drivers/scsi/sr_ioctl.o CC drivers/scsi/sr_vendor.o CC drivers/scsi/sg.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/cursgf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/cursgp102.o CC drivers/scsi/ch.o CC drivers/scsi/ses.o CC drivers/scsi/scsi_sysfs.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/cursgv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/oimmnv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/oimmgf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/oimmgp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/nv04.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/nv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/gf100.o AR drivers/scsi/qla2xxx/built-in.a CC drivers/gpu/drm/nouveau/nvkm/engine/dma/gf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/gv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/user.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usernv04.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usergf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usernv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usergf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv04.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usergv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv10.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv40.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv17.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/g84.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk110.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk208.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk20a.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gm107.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gm200.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gm20b.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gp100.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gp10b.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/tu102.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/channv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv04.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv17.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv10.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmag84.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifonv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifog84.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifotu102.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/usertu102.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/usergv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv04.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv15.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv17.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv20.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv25.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv2a.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv30.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv34.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv35.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv44.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv40.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/g84.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gt200.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/mcp79.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gt215.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/mcp89.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf104.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf108.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf110.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf117.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110b.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk208.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gm200.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gm20b.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp100.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp104.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp107.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp10b.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv40.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf104.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf108.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf110.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk20a.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm200.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp100.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp104.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm20b.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp107.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv40.o CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv44.o CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/g84.o CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/g98.o CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/gt215.o CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/msppp/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/gk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/msppp/g98.o CC drivers/gpu/drm/nouveau/nvkm/engine/msppp/gt215.o CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/msppp/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/g98.o CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/gt215.o CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/mcp89.o CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/gk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/nvdec/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/nvdec/gp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/nv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/g84.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gt200.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gt215.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gf108.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gf117.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/sec/g98.o CC drivers/gpu/drm/nouveau/nvkm/engine/sec2/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/sec2/gp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/sec2/tu102.o CC drivers/gpu/drm/nouveau/nvkm/engine/sw/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/sw/nv04.o CC drivers/gpu/drm/nouveau/nvkm/engine/sw/nv10.o CC drivers/gpu/drm/nouveau/nvkm/engine/sw/nv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/sw/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/sw/chan.o CC drivers/gpu/drm/nouveau/nvkm/engine/sw/nvsw.o CC drivers/gpu/drm/nouveau/nvkm/engine/vp/g84.o CC drivers/gpu/drm/nouveau/nouveau_acpi.o CC drivers/gpu/drm/nouveau/nouveau_debugfs.o CC drivers/gpu/drm/nouveau/nouveau_drm.o CC drivers/gpu/drm/nouveau/nouveau_hwmon.o CC drivers/gpu/drm/nouveau/nouveau_ioc32.o CC drivers/gpu/drm/nouveau/nouveau_led.o CC drivers/gpu/drm/nouveau/nouveau_nvif.o CC drivers/gpu/drm/nouveau/nouveau_usif.o CC drivers/gpu/drm/nouveau/nouveau_vga.o CC drivers/gpu/drm/nouveau/nouveau_bo.o CC drivers/gpu/drm/nouveau/nouveau_gem.o CC drivers/gpu/drm/nouveau/nouveau_mem.o CC drivers/gpu/drm/nouveau/nouveau_prime.o CC drivers/gpu/drm/nouveau/nouveau_sgdma.o CC drivers/gpu/drm/nouveau/nouveau_ttm.o CC drivers/gpu/drm/nouveau/nouveau_vmm.o CC drivers/gpu/drm/nouveau/nouveau_display.o CC drivers/gpu/drm/nouveau/nouveau_backlight.o CC drivers/gpu/drm/nouveau/nouveau_bios.o CC drivers/gpu/drm/nouveau/nouveau_connector.o CC drivers/gpu/drm/nouveau/nv04_fbcon.o CC drivers/gpu/drm/nouveau/nv50_fbcon.o CC drivers/gpu/drm/nouveau/nvc0_fbcon.o CC drivers/gpu/drm/nouveau/nouveau_dp.o CC drivers/gpu/drm/nouveau/nouveau_fbcon.o CC drivers/gpu/drm/nouveau/dispnv04/arb.o CC drivers/gpu/drm/nouveau/dispnv04/cursor.o CC drivers/gpu/drm/nouveau/dispnv04/crtc.o CC drivers/gpu/drm/nouveau/dispnv04/dfp.o CC drivers/gpu/drm/nouveau/dispnv04/dac.o CC drivers/gpu/drm/nouveau/dispnv04/hw.o CC drivers/gpu/drm/nouveau/dispnv04/overlay.o CC drivers/gpu/drm/nouveau/dispnv04/tvnv17.o CC drivers/gpu/drm/nouveau/dispnv04/tvmodesnv17.o CC drivers/gpu/drm/nouveau/dispnv04/tvnv04.o CC drivers/gpu/drm/nouveau/dispnv50/core.o CC drivers/gpu/drm/nouveau/dispnv50/lut.o CC drivers/gpu/drm/nouveau/dispnv04/disp.o CC drivers/gpu/drm/nouveau/dispnv50/disp.o CC drivers/gpu/drm/nouveau/dispnv50/core507d.o AR drivers/scsi/built-in.a CC drivers/gpu/drm/nouveau/dispnv50/core827d.o CC drivers/gpu/drm/nouveau/dispnv50/core907d.o CC drivers/gpu/drm/nouveau/dispnv50/core917d.o CC drivers/gpu/drm/nouveau/dispnv50/corec37d.o CC drivers/gpu/drm/nouveau/dispnv50/corec57d.o CC drivers/gpu/drm/nouveau/dispnv50/dac507d.o CC drivers/gpu/drm/nouveau/dispnv50/dac907d.o CC drivers/gpu/drm/nouveau/dispnv50/pior507d.o CC drivers/gpu/drm/nouveau/dispnv50/sor507d.o CC drivers/gpu/drm/nouveau/dispnv50/head507d.o CC drivers/gpu/drm/nouveau/dispnv50/head.o CC drivers/gpu/drm/nouveau/dispnv50/sorc37d.o CC drivers/gpu/drm/nouveau/dispnv50/sor907d.o CC drivers/gpu/drm/nouveau/dispnv50/head827d.o CC drivers/gpu/drm/nouveau/dispnv50/head917d.o CC drivers/gpu/drm/nouveau/dispnv50/head907d.o CC drivers/gpu/drm/nouveau/dispnv50/headc37d.o CC drivers/gpu/drm/nouveau/dispnv50/wimm.o CC drivers/gpu/drm/nouveau/dispnv50/headc57d.o CC drivers/gpu/drm/nouveau/dispnv50/wimmc37b.o CC drivers/gpu/drm/nouveau/dispnv50/wndwc37e.o CC drivers/gpu/drm/nouveau/dispnv50/wndw.o CC drivers/gpu/drm/nouveau/dispnv50/base.o CC drivers/gpu/drm/nouveau/dispnv50/wndwc57e.o CC drivers/gpu/drm/nouveau/dispnv50/base507c.o CC drivers/gpu/drm/nouveau/dispnv50/base827c.o CC drivers/gpu/drm/nouveau/dispnv50/base907c.o CC drivers/gpu/drm/nouveau/dispnv50/base917c.o CC drivers/gpu/drm/nouveau/dispnv50/curs.o CC drivers/gpu/drm/nouveau/dispnv50/curs507a.o CC drivers/gpu/drm/nouveau/dispnv50/curs907a.o CC drivers/gpu/drm/nouveau/dispnv50/cursc37a.o CC drivers/gpu/drm/nouveau/dispnv50/oimm.o CC drivers/gpu/drm/nouveau/dispnv50/oimm507b.o CC drivers/gpu/drm/nouveau/dispnv50/ovly.o CC drivers/gpu/drm/nouveau/dispnv50/ovly507e.o CC drivers/gpu/drm/nouveau/dispnv50/ovly827e.o CC drivers/gpu/drm/nouveau/dispnv50/ovly907e.o CC drivers/gpu/drm/nouveau/dispnv50/ovly917e.o CC drivers/gpu/drm/nouveau/nouveau_abi16.o CC drivers/gpu/drm/nouveau/nouveau_dma.o CC drivers/gpu/drm/nouveau/nouveau_chan.o CC drivers/gpu/drm/nouveau/nouveau_fence.o CC drivers/gpu/drm/nouveau/nv04_fence.o CC drivers/gpu/drm/nouveau/nv10_fence.o CC drivers/gpu/drm/nouveau/nv17_fence.o CC drivers/gpu/drm/nouveau/nv50_fence.o CC drivers/gpu/drm/nouveau/nv84_fence.o CC drivers/gpu/drm/nouveau/nvc0_fence.o AR drivers/gpu/drm/nouveau/built-in.a AR drivers/gpu/drm/built-in.a AR drivers/gpu/built-in.a Makefile:1051: recipe for target 'drivers' failed make: *** [drivers] Error 2 Error text is too large and was truncated, full error text is at: https://syzkaller.appspot.com/x/error.txt?x=17a6b2f8a00000 Tested on: commit: 43151d6c usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer compiler: gcc (GCC) 9.0.0 20181231 (experimental) patch: https://syzkaller.appspot.com/x/patch.diff?x=173a6c54a00000 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb 2019-05-17 21:01 ` syzbot @ 2019-05-18 15:13 ` Alan Stern 2019-05-18 15:50 ` syzbot 0 siblings, 1 reply; 21+ messages in thread From: Alan Stern @ 2019-05-18 15:13 UTC (permalink / raw) To: syzbot Cc: andreyknvl, chunkeey, chunkeey, davem, kvalo, Kernel development list, USB list, linux-wireless, netdev, Oliver Neukum, syzkaller-bugs On Fri, 17 May 2019, syzbot wrote: > Hello, > > syzbot tried to test the proposed patch but build/boot failed: Drat. Mistake in the patch. Let's try again. Incidentally, as far as I can tell there's no point in having the usb_get_dev() in p54u_probe() and usb_put_dev() in p54u_disconnect(). The device structure is guaranteed not to be deallocated while a driver is bound to any of its interfaces, so taking an extra reference won't make any difference. On the other hand, I do see some problems in the firmware-load callback. First, it calls device_release_driver() without first checking that the interface is still bound to the p54u driver. Second, it shouldn't call device_release_driver() at all -- it should call usb_driver_release_interface(). It doesn't want to unbind the USB device's driver; it wants to unbind the interface's driver. And third, to do this it needs to acquire udev's device lock, not the lock for udev's parent. Alan Stern #syz test: https://github.com/google/kasan.git usb-fuzzer drivers/net/wireless/intersil/p54/p54usb.c | 3 +++ 1 file changed, 3 insertions(+) Index: usb-devel/drivers/net/wireless/intersil/p54/p54usb.c =================================================================== --- usb-devel.orig/drivers/net/wireless/intersil/p54/p54usb.c +++ usb-devel/drivers/net/wireless/intersil/p54/p54usb.c @@ -923,6 +923,7 @@ static void p54u_load_firmware_cb(const struct usb_device *udev = priv->udev; int err; + pr_info("%s: priv->udev = %px\n", __func__, udev); complete(&priv->fw_wait_load); if (firmware) { priv->fw = firmware; @@ -969,6 +970,8 @@ static int p54u_load_firmware(struct iee if (i < 0) return i; + dev_info(&udev->dev, "%s: udev @ %px, dev.parent @ %px\n", + __func__, udev, &udev->dev.parent); dev_info(&priv->udev->dev, "Loading firmware file %s\n", p54u_fwlist[i].fw); ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb 2019-05-18 15:13 ` Alan Stern @ 2019-05-18 15:50 ` syzbot 2019-05-18 16:32 ` Alan Stern 0 siblings, 1 reply; 21+ messages in thread From: syzbot @ 2019-05-18 15:50 UTC (permalink / raw) To: andreyknvl, chunkeey, chunkeey, davem, kvalo, linux-kernel, linux-usb, linux-wireless, netdev, oneukum, stern, syzkaller-bugs Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: KASAN: slab-out-of-bounds Read in p54u_load_firmware_cb usb 6-1: Direct firmware load for isl3887usb failed with error -2 p54u_load_firmware_cb: priv->udev = ffff88809ad5bb80 usb 6-1: Firmware not found. ================================================================== BUG: KASAN: slab-out-of-bounds in p54u_load_firmware_cb+0x3c9/0x45f drivers/net/wireless/intersil/p54/p54usb.c:937 Read of size 8 at addr ffff88809abab588 by task kworker/1:8/5526 CPU: 1 PID: 5526 Comm: kworker/1:8 Not tainted 5.1.0-rc3-g43151d6-dirty #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events request_firmware_work_func Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe8/0x16e lib/dump_stack.c:113 print_address_description+0x6c/0x236 mm/kasan/report.c:187 kasan_report.cold+0x1a/0x3c mm/kasan/report.c:317 p54u_load_firmware_cb+0x3c9/0x45f drivers/net/wireless/intersil/p54/p54usb.c:937 request_firmware_work_func+0x12d/0x249 drivers/base/firmware_loader/main.c:785 process_one_work+0x90f/0x1580 kernel/workqueue.c:2269 worker_thread+0x9b/0xe20 kernel/workqueue.c:2415 kthread+0x313/0x420 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Allocated by task 5503: set_track mm/kasan/common.c:87 [inline] __kasan_kmalloc mm/kasan/common.c:497 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:470 slab_post_alloc_hook mm/slab.h:437 [inline] slab_alloc_node mm/slub.c:2756 [inline] __kmalloc_node_track_caller+0xf3/0x320 mm/slub.c:4372 __kmalloc_reserve.isra.0+0x3e/0xf0 net/core/skbuff.c:140 __alloc_skb+0xf4/0x5a0 net/core/skbuff.c:208 alloc_skb include/linux/skbuff.h:1058 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1182 [inline] netlink_sendmsg+0x8db/0xcd0 net/netlink/af_netlink.c:1900 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0xda/0x130 net/socket.c:661 ___sys_sendmsg+0x80b/0x930 net/socket.c:2260 __sys_sendmsg+0xf1/0x1b0 net/socket.c:2298 do_syscall_64+0xcf/0x4f0 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 5503: set_track mm/kasan/common.c:87 [inline] __kasan_slab_free+0x130/0x180 mm/kasan/common.c:459 slab_free_hook mm/slub.c:1429 [inline] slab_free_freelist_hook+0x5e/0x140 mm/slub.c:1456 slab_free mm/slub.c:3003 [inline] kfree+0xce/0x290 mm/slub.c:3958 skb_free_head+0x90/0xb0 net/core/skbuff.c:557 skb_release_data+0x543/0x8b0 net/core/skbuff.c:577 skb_release_all+0x4b/0x60 net/core/skbuff.c:631 __kfree_skb net/core/skbuff.c:645 [inline] consume_skb net/core/skbuff.c:705 [inline] consume_skb+0xc5/0x2f0 net/core/skbuff.c:699 netlink_unicast_kernel net/netlink/af_netlink.c:1311 [inline] netlink_unicast+0x4e2/0x690 net/netlink/af_netlink.c:1336 netlink_sendmsg+0x810/0xcd0 net/netlink/af_netlink.c:1925 sock_sendmsg_nosec net/socket.c:651 [inline] sock_sendmsg+0xda/0x130 net/socket.c:661 ___sys_sendmsg+0x80b/0x930 net/socket.c:2260 __sys_sendmsg+0xf1/0x1b0 net/socket.c:2298 do_syscall_64+0xcf/0x4f0 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff88809abab180 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 8 bytes to the right of 1024-byte region [ffff88809abab180, ffff88809abab580) The buggy address belongs to the page: page:ffffea00026aea00 count:1 mapcount:0 mapping:ffff88812c3f4a00 index:0x0 compound_mapcount: 0 flags: 0xfff00000010200(slab|head) raw: 00fff00000010200 dead000000000100 dead000000000200 ffff88812c3f4a00 raw: 0000000000000000 00000000000e000e 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88809abab480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88809abab500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff88809abab580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88809abab600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88809abab680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Tested on: commit: 43151d6c 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=108a0108a00000 kernel config: https://syzkaller.appspot.com/x/.config?x=4183eeef650d1234 compiler: gcc (GCC) 9.0.0 20181231 (experimental) patch: https://syzkaller.appspot.com/x/patch.diff?x=1292f852a00000 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb 2019-05-18 15:50 ` syzbot @ 2019-05-18 16:32 ` Alan Stern 2019-05-18 16:50 ` syzbot 0 siblings, 1 reply; 21+ messages in thread From: Alan Stern @ 2019-05-18 16:32 UTC (permalink / raw) To: syzbot Cc: andreyknvl, chunkeey, chunkeey, davem, kvalo, linux-kernel, linux-usb, linux-wireless, netdev, oneukum, syzkaller-bugs On Sat, 18 May 2019, syzbot wrote: > Hello, > > syzbot has tested the proposed patch but the reproducer still triggered > crash: > KASAN: slab-out-of-bounds Read in p54u_load_firmware_cb > > usb 6-1: Direct firmware load for isl3887usb failed with error -2 > p54u_load_firmware_cb: priv->udev = ffff88809ad5bb80 > usb 6-1: Firmware not found. > ================================================================== > BUG: KASAN: slab-out-of-bounds in p54u_load_firmware_cb+0x3c9/0x45f > drivers/net/wireless/intersil/p54/p54usb.c:937 > Read of size 8 at addr ffff88809abab588 by task kworker/1:8/5526 If you look at the full console log, you'll see that this address is different from all the addresses printed out earlier. Not what you would expect. Which makes me wonder: Suppose a disconnect occurs before the firmware loader callback runs? p54_disconnect() will get stuck waiting for the priv->fw_load_wait completion to fire. But when the callback runs, the first thing it does is activate the completion. So now p54_disconnect() can finish doing its thing, including deallocating all the private data structures. Then when p54u_load_firmware_cb() tries to read the contents of priv, it ends up accessing deallocated memory! The patch below tries to do things the right way. Alan Stern #syz test: https://github.com/google/kasan.git usb-fuzzer drivers/net/wireless/intersil/p54/p54usb.c | 37 +++++++++++------------------ 1 file changed, 15 insertions(+), 22 deletions(-) Index: usb-devel/drivers/net/wireless/intersil/p54/p54usb.c =================================================================== --- usb-devel.orig/drivers/net/wireless/intersil/p54/p54usb.c +++ usb-devel/drivers/net/wireless/intersil/p54/p54usb.c @@ -33,6 +33,8 @@ MODULE_ALIAS("prism54usb"); MODULE_FIRMWARE("isl3886usb"); MODULE_FIRMWARE("isl3887usb"); +static struct usb_driver p54u_driver; + /* * Note: * @@ -921,9 +923,9 @@ static void p54u_load_firmware_cb(const { struct p54u_priv *priv = context; struct usb_device *udev = priv->udev; + struct usb_interface *intf = priv->intf; int err; - complete(&priv->fw_wait_load); if (firmware) { priv->fw = firmware; err = p54u_start_ops(priv); @@ -932,23 +934,19 @@ static void p54u_load_firmware_cb(const dev_err(&udev->dev, "Firmware not found.\n"); } - if (err) { - struct device *parent = priv->udev->dev.parent; - - dev_err(&udev->dev, "failed to initialize device (%d)\n", err); - - if (parent) - device_lock(parent); + complete(&priv->fw_wait_load); + /* + * At this point p54u_disconnect may have already freed + * the "priv" context. Do not use it anymore! + */ + priv = NULL; - device_release_driver(&udev->dev); - /* - * At this point p54u_disconnect has already freed - * the "priv" context. Do not use it anymore! - */ - priv = NULL; + if (err) { + dev_err(&intf->dev, "failed to initialize device (%d)\n", err); - if (parent) - device_unlock(parent); + usb_lock_device(udev); + usb_driver_release_interface(intf, &p54u_driver); + usb_unlock_device(udev); } usb_put_dev(udev); @@ -1011,8 +1009,6 @@ static int p54u_probe(struct usb_interfa skb_queue_head_init(&priv->rx_queue); init_usb_anchor(&priv->submitted); - usb_get_dev(udev); - /* really lazy and simple way of figuring out if we're a 3887 */ /* TODO: should just stick the identification in the device table */ i = intf->altsetting->desc.bNumEndpoints; @@ -1053,10 +1049,8 @@ static int p54u_probe(struct usb_interfa priv->upload_fw = p54u_upload_firmware_net2280; } err = p54u_load_firmware(dev, intf); - if (err) { - usb_put_dev(udev); + if (err) p54_free_common(dev); - } return err; } @@ -1072,7 +1066,6 @@ static void p54u_disconnect(struct usb_i wait_for_completion(&priv->fw_wait_load); p54_unregister_common(dev); - usb_put_dev(interface_to_usbdev(intf)); release_firmware(priv->fw); p54_free_common(dev); } ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb 2019-05-18 16:32 ` Alan Stern @ 2019-05-18 16:50 ` syzbot 2019-05-18 17:01 ` Alan Stern 0 siblings, 1 reply; 21+ messages in thread From: syzbot @ 2019-05-18 16:50 UTC (permalink / raw) To: andreyknvl, chunkeey, chunkeey, davem, kvalo, linux-kernel, linux-usb, linux-wireless, netdev, oneukum, stern, syzkaller-bugs Hello, syzbot tried to test the proposed patch but build/boot failed: si/sg.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/rootgp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/rootgv100.o CC drivers/scsi/ch.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/roottu102.o CC drivers/scsi/ses.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/changf119.o CC drivers/scsi/scsi_sysfs.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/changv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/dmacnv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/dmacgf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/dmacgp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/dmacgv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/basenv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/baseg84.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/basegf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/basegp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/corenv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/coreg84.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/coreg94.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/coregf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/coregk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/coregp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/coregv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/ovlynv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/ovlyg84.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/ovlygt200.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/ovlygf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/ovlygk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/ovlygp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/wimmgv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/wndwgv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/piocnv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/piocgf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/cursgf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/cursgp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/cursnv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/cursgv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/oimmnv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/oimmgf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/disp/oimmgp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/nv04.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/nv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/gf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/gv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/user.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usernv04.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usernv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usergf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usergf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/dma/usergv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv04.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv10.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv17.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv40.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/nv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/g84.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk110.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk208.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gm107.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk20a.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gm200.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gm20b.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gp100.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gp10b.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/tu102.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/channv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/chang84.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv04.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv17.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv10.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv40.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmanv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/dmag84.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifonv50.o AR drivers/net/ethernet/sun/built-in.a CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifog84.o AR drivers/net/ethernet/built-in.a CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifogv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/usergv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/usertu102.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv04.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv15.o CC drivers/gpu/drm/nouveau/nvkm/engine/fifo/gpfifotu102.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv17.o scripts/Makefile.build:486: recipe for target 'drivers/net' failed make[1]: *** [drivers/net] Error 2 make[1]: *** Waiting for unfinished jobs.... CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv25.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv20.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv2a.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv30.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv34.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv35.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv40.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv44.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/nv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/g84.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gt200.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/mcp79.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gt215.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/mcp89.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf104.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf110.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf108.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf117.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110b.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk208.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gk20a.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gm107.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gm200.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gm20b.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp100.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp104.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp107.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/gp10b.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv40.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf104.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf108.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf110.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf119.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk110b.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk208.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgk20a.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm107.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm200.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm20b.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp100.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp104.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgp107.o CC drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgv100.o CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.o CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv40.o CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv44.o CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/g84.o CC drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/g98.o CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/gt215.o CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/mspdec/gk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/msppp/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/msppp/g98.o CC drivers/gpu/drm/nouveau/nvkm/engine/msppp/gt215.o CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/msppp/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/g98.o CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/mcp89.o CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/gt215.o CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/msvld/gk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/nvdec/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/nvdec/gp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/g84.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gt200.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gt215.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gf108.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gf117.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/gk104.o CC drivers/gpu/drm/nouveau/nvkm/engine/sec2/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/sec/g98.o CC drivers/gpu/drm/nouveau/nvkm/engine/pm/nv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/sec2/gp102.o CC drivers/gpu/drm/nouveau/nvkm/engine/sec2/tu102.o CC drivers/gpu/drm/nouveau/nvkm/engine/sw/base.o CC drivers/gpu/drm/nouveau/nvkm/engine/sw/nv04.o CC drivers/gpu/drm/nouveau/nvkm/engine/sw/nv10.o CC drivers/gpu/drm/nouveau/nvkm/engine/sw/nv50.o CC drivers/gpu/drm/nouveau/nvkm/engine/sw/gf100.o CC drivers/gpu/drm/nouveau/nvkm/engine/sw/chan.o CC drivers/gpu/drm/nouveau/nouveau_acpi.o CC drivers/gpu/drm/nouveau/nvkm/engine/vp/g84.o CC drivers/gpu/drm/nouveau/nvkm/engine/sw/nvsw.o CC drivers/gpu/drm/nouveau/nouveau_debugfs.o CC drivers/gpu/drm/nouveau/nouveau_drm.o CC drivers/gpu/drm/nouveau/nouveau_hwmon.o CC drivers/gpu/drm/nouveau/nouveau_ioc32.o CC drivers/gpu/drm/nouveau/nouveau_led.o CC drivers/gpu/drm/nouveau/nouveau_nvif.o CC drivers/gpu/drm/nouveau/nouveau_usif.o CC drivers/gpu/drm/nouveau/nouveau_bo.o CC drivers/gpu/drm/nouveau/nouveau_gem.o CC drivers/gpu/drm/nouveau/nouveau_mem.o CC drivers/gpu/drm/nouveau/nouveau_backlight.o CC drivers/gpu/drm/nouveau/nouveau_vga.o CC drivers/gpu/drm/nouveau/nouveau_vmm.o CC drivers/gpu/drm/nouveau/nouveau_ttm.o CC drivers/gpu/drm/nouveau/nouveau_bios.o CC drivers/gpu/drm/nouveau/nouveau_prime.o CC drivers/gpu/drm/nouveau/nouveau_connector.o CC drivers/gpu/drm/nouveau/nouveau_sgdma.o CC drivers/gpu/drm/nouveau/nouveau_dp.o CC drivers/gpu/drm/nouveau/nouveau_display.o CC drivers/gpu/drm/nouveau/nv04_fbcon.o CC drivers/gpu/drm/nouveau/nv50_fbcon.o CC drivers/gpu/drm/nouveau/nouveau_fbcon.o CC drivers/gpu/drm/nouveau/nvc0_fbcon.o CC drivers/gpu/drm/nouveau/dispnv04/arb.o CC drivers/gpu/drm/nouveau/dispnv04/crtc.o CC drivers/gpu/drm/nouveau/dispnv04/cursor.o CC drivers/gpu/drm/nouveau/dispnv04/dac.o CC drivers/gpu/drm/nouveau/dispnv04/dfp.o CC drivers/gpu/drm/nouveau/dispnv04/disp.o CC drivers/gpu/drm/nouveau/dispnv04/hw.o CC drivers/gpu/drm/nouveau/dispnv04/overlay.o CC drivers/gpu/drm/nouveau/dispnv04/tvmodesnv17.o CC drivers/gpu/drm/nouveau/dispnv04/tvnv04.o AR drivers/scsi/built-in.a CC drivers/gpu/drm/nouveau/dispnv04/tvnv17.o CC drivers/gpu/drm/nouveau/dispnv50/disp.o CC drivers/gpu/drm/nouveau/dispnv50/lut.o CC drivers/gpu/drm/nouveau/dispnv50/core507d.o CC drivers/gpu/drm/nouveau/dispnv50/core.o CC drivers/gpu/drm/nouveau/dispnv50/core907d.o CC drivers/gpu/drm/nouveau/dispnv50/core827d.o CC drivers/gpu/drm/nouveau/dispnv50/core917d.o CC drivers/gpu/drm/nouveau/dispnv50/corec37d.o CC drivers/gpu/drm/nouveau/dispnv50/corec57d.o CC drivers/gpu/drm/nouveau/dispnv50/dac907d.o CC drivers/gpu/drm/nouveau/dispnv50/dac507d.o CC drivers/gpu/drm/nouveau/dispnv50/pior507d.o CC drivers/gpu/drm/nouveau/dispnv50/sor507d.o CC drivers/gpu/drm/nouveau/dispnv50/sor907d.o CC drivers/gpu/drm/nouveau/dispnv50/sorc37d.o CC drivers/gpu/drm/nouveau/dispnv50/head.o CC drivers/gpu/drm/nouveau/dispnv50/head507d.o CC drivers/gpu/drm/nouveau/dispnv50/head827d.o CC drivers/gpu/drm/nouveau/dispnv50/head907d.o CC drivers/gpu/drm/nouveau/dispnv50/headc37d.o CC drivers/gpu/drm/nouveau/dispnv50/head917d.o CC drivers/gpu/drm/nouveau/dispnv50/headc57d.o CC drivers/gpu/drm/nouveau/dispnv50/wimm.o CC drivers/gpu/drm/nouveau/dispnv50/wimmc37b.o CC drivers/gpu/drm/nouveau/dispnv50/wndwc37e.o CC drivers/gpu/drm/nouveau/dispnv50/base.o CC drivers/gpu/drm/nouveau/dispnv50/wndwc57e.o CC drivers/gpu/drm/nouveau/dispnv50/wndw.o CC drivers/gpu/drm/nouveau/dispnv50/base907c.o CC drivers/gpu/drm/nouveau/dispnv50/base827c.o CC drivers/gpu/drm/nouveau/dispnv50/base507c.o CC drivers/gpu/drm/nouveau/dispnv50/base917c.o CC drivers/gpu/drm/nouveau/dispnv50/curs.o CC drivers/gpu/drm/nouveau/dispnv50/curs507a.o CC drivers/gpu/drm/nouveau/dispnv50/curs907a.o CC drivers/gpu/drm/nouveau/dispnv50/cursc37a.o CC drivers/gpu/drm/nouveau/dispnv50/oimm.o CC drivers/gpu/drm/nouveau/dispnv50/oimm507b.o CC drivers/gpu/drm/nouveau/dispnv50/ovly.o CC drivers/gpu/drm/nouveau/dispnv50/ovly507e.o CC drivers/gpu/drm/nouveau/dispnv50/ovly827e.o CC drivers/gpu/drm/nouveau/dispnv50/ovly907e.o CC drivers/gpu/drm/nouveau/dispnv50/ovly917e.o CC drivers/gpu/drm/nouveau/nouveau_abi16.o CC drivers/gpu/drm/nouveau/nouveau_chan.o CC drivers/gpu/drm/nouveau/nv04_fence.o CC drivers/gpu/drm/nouveau/nouveau_fence.o CC drivers/gpu/drm/nouveau/nouveau_dma.o CC drivers/gpu/drm/nouveau/nv10_fence.o CC drivers/gpu/drm/nouveau/nv50_fence.o CC drivers/gpu/drm/nouveau/nv17_fence.o CC drivers/gpu/drm/nouveau/nv84_fence.o CC drivers/gpu/drm/nouveau/nvc0_fence.o AR drivers/gpu/drm/nouveau/built-in.a AR drivers/gpu/drm/built-in.a AR drivers/gpu/built-in.a Makefile:1051: recipe for target 'drivers' failed make: *** [drivers] Error 2 Error text is too large and was truncated, full error text is at: https://syzkaller.appspot.com/x/error.txt?x=164a0108a00000 Tested on: commit: 43151d6c usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer compiler: gcc (GCC) 9.0.0 20181231 (experimental) patch: https://syzkaller.appspot.com/x/patch.diff?x=15d1ef02a00000 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb 2019-05-18 16:50 ` syzbot @ 2019-05-18 17:01 ` Alan Stern 2019-05-18 17:36 ` syzbot 0 siblings, 1 reply; 21+ messages in thread From: Alan Stern @ 2019-05-18 17:01 UTC (permalink / raw) To: syzbot Cc: andreyknvl, chunkeey, chunkeey, davem, kvalo, linux-kernel, linux-usb, linux-wireless, netdev, oneukum, syzkaller-bugs On Sat, 18 May 2019, syzbot wrote: > Hello, > > syzbot tried to test the proposed patch but build/boot failed: One of these times I'll get it right... Alan Stern #syz test: https://github.com/google/kasan.git usb-fuzzer drivers/net/wireless/intersil/p54/p54usb.c | 37 +++++++++++------------------ 1 file changed, 15 insertions(+), 22 deletions(-) Index: usb-devel/drivers/net/wireless/intersil/p54/p54usb.c =================================================================== --- usb-devel.orig/drivers/net/wireless/intersil/p54/p54usb.c +++ usb-devel/drivers/net/wireless/intersil/p54/p54usb.c @@ -33,6 +33,8 @@ MODULE_ALIAS("prism54usb"); MODULE_FIRMWARE("isl3886usb"); MODULE_FIRMWARE("isl3887usb"); +static struct usb_driver p54u_driver; + /* * Note: * @@ -921,9 +923,9 @@ static void p54u_load_firmware_cb(const { struct p54u_priv *priv = context; struct usb_device *udev = priv->udev; + struct usb_interface *intf = priv->intf; int err; - complete(&priv->fw_wait_load); if (firmware) { priv->fw = firmware; err = p54u_start_ops(priv); @@ -932,23 +934,19 @@ static void p54u_load_firmware_cb(const dev_err(&udev->dev, "Firmware not found.\n"); } - if (err) { - struct device *parent = priv->udev->dev.parent; - - dev_err(&udev->dev, "failed to initialize device (%d)\n", err); - - if (parent) - device_lock(parent); + complete(&priv->fw_wait_load); + /* + * At this point p54u_disconnect may have already freed + * the "priv" context. Do not use it anymore! + */ + priv = NULL; - device_release_driver(&udev->dev); - /* - * At this point p54u_disconnect has already freed - * the "priv" context. Do not use it anymore! - */ - priv = NULL; + if (err) { + dev_err(&intf->dev, "failed to initialize device (%d)\n", err); - if (parent) - device_unlock(parent); + usb_lock_device(udev); + usb_driver_release_interface(&p54u_driver, intf); + usb_unlock_device(udev); } usb_put_dev(udev); @@ -1011,8 +1009,6 @@ static int p54u_probe(struct usb_interfa skb_queue_head_init(&priv->rx_queue); init_usb_anchor(&priv->submitted); - usb_get_dev(udev); - /* really lazy and simple way of figuring out if we're a 3887 */ /* TODO: should just stick the identification in the device table */ i = intf->altsetting->desc.bNumEndpoints; @@ -1053,10 +1049,8 @@ static int p54u_probe(struct usb_interfa priv->upload_fw = p54u_upload_firmware_net2280; } err = p54u_load_firmware(dev, intf); - if (err) { - usb_put_dev(udev); + if (err) p54_free_common(dev); - } return err; } @@ -1072,7 +1066,6 @@ static void p54u_disconnect(struct usb_i wait_for_completion(&priv->fw_wait_load); p54_unregister_common(dev); - usb_put_dev(interface_to_usbdev(intf)); release_firmware(priv->fw); p54_free_common(dev); } ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb 2019-05-18 17:01 ` Alan Stern @ 2019-05-18 17:36 ` syzbot 2019-05-18 17:49 ` Alan Stern 0 siblings, 1 reply; 21+ messages in thread From: syzbot @ 2019-05-18 17:36 UTC (permalink / raw) To: andreyknvl, chunkeey, chunkeey, davem, kvalo, linux-kernel, linux-usb, linux-wireless, netdev, oneukum, stern, syzkaller-bugs Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: KASAN: use-after-free Read in usb_driver_release_interface usb 1-1: Loading firmware file isl3887usb usb 1-1: Direct firmware load for isl3887usb failed with error -2 usb 1-1: Firmware not found. p54usb 1-1:0.143: failed to initialize device (-2) ================================================================== BUG: KASAN: use-after-free in usb_driver_release_interface+0x16b/0x190 drivers/usb/core/driver.c:584 Read of size 8 at addr ffff88808fc31218 by task kworker/0:1/12 CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.1.0-rc3-g43151d6-dirty #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events request_firmware_work_func Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe8/0x16e lib/dump_stack.c:113 print_address_description+0x6c/0x236 mm/kasan/report.c:187 kasan_report.cold+0x1a/0x3c mm/kasan/report.c:317 usb_driver_release_interface+0x16b/0x190 drivers/usb/core/driver.c:584 p54u_load_firmware_cb+0x390/0x420 drivers/net/wireless/intersil/p54/p54usb.c:948 request_firmware_work_func+0x12d/0x249 drivers/base/firmware_loader/main.c:785 process_one_work+0x90f/0x1580 kernel/workqueue.c:2269 worker_thread+0x9b/0xe20 kernel/workqueue.c:2415 kthread+0x313/0x420 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Allocated by task 12: set_track mm/kasan/common.c:87 [inline] __kasan_kmalloc mm/kasan/common.c:497 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:470 kmalloc include/linux/slab.h:547 [inline] kzalloc include/linux/slab.h:742 [inline] usb_set_configuration+0x2e0/0x1740 drivers/usb/core/message.c:1846 generic_probe+0xa2/0xda drivers/usb/core/generic.c:210 usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266 really_probe+0x2da/0xb10 drivers/base/dd.c:509 driver_probe_device+0x21d/0x350 drivers/base/dd.c:671 __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454 __device_attach+0x223/0x3a0 drivers/base/dd.c:844 bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514 device_add+0xad2/0x16e0 drivers/base/core.c:2106 usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534 hub_port_connect drivers/usb/core/hub.c:5089 [inline] hub_port_connect_change drivers/usb/core/hub.c:5204 [inline] port_event drivers/usb/core/hub.c:5350 [inline] hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432 process_one_work+0x90f/0x1580 kernel/workqueue.c:2269 worker_thread+0x9b/0xe20 kernel/workqueue.c:2415 kthread+0x313/0x420 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Freed by task 5394: set_track mm/kasan/common.c:87 [inline] __kasan_slab_free+0x130/0x180 mm/kasan/common.c:459 slab_free_hook mm/slub.c:1429 [inline] slab_free_freelist_hook+0x5e/0x140 mm/slub.c:1456 slab_free mm/slub.c:3003 [inline] kfree+0xce/0x290 mm/slub.c:3958 device_release+0x7d/0x210 drivers/base/core.c:1064 kobject_cleanup lib/kobject.c:662 [inline] kobject_release lib/kobject.c:691 [inline] kref_put include/linux/kref.h:67 [inline] kobject_put+0x1df/0x4f0 lib/kobject.c:708 put_device+0x21/0x30 drivers/base/core.c:2205 usb_disable_device+0x309/0x790 drivers/usb/core/message.c:1244 usb_disconnect+0x298/0x870 drivers/usb/core/hub.c:2197 hub_port_connect drivers/usb/core/hub.c:4940 [inline] hub_port_connect_change drivers/usb/core/hub.c:5204 [inline] port_event drivers/usb/core/hub.c:5350 [inline] hub_event+0xcd2/0x3b00 drivers/usb/core/hub.c:5432 process_one_work+0x90f/0x1580 kernel/workqueue.c:2269 worker_thread+0x9b/0xe20 kernel/workqueue.c:2415 kthread+0x313/0x420 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 The buggy address belongs to the object at ffff88808fc31100 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 280 bytes inside of 2048-byte region [ffff88808fc31100, ffff88808fc31900) The buggy address belongs to the page: page:ffffea00023f0c00 count:1 mapcount:0 mapping:ffff88812c3f4800 index:0x0 compound_mapcount: 0 flags: 0xfff00000010200(slab|head) raw: 00fff00000010200 dead000000000100 dead000000000200 ffff88812c3f4800 raw: 0000000000000000 00000000000f000f 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88808fc31100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88808fc31180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff88808fc31200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88808fc31280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88808fc31300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Tested on: commit: 43151d6c 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=148b9428a00000 kernel config: https://syzkaller.appspot.com/x/.config?x=4183eeef650d1234 compiler: gcc (GCC) 9.0.0 20181231 (experimental) patch: https://syzkaller.appspot.com/x/patch.diff?x=17642018a00000 ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb 2019-05-18 17:36 ` syzbot @ 2019-05-18 17:49 ` Alan Stern 2019-05-18 18:31 ` syzbot 2019-05-18 20:11 ` Christian Lamparter 0 siblings, 2 replies; 21+ messages in thread From: Alan Stern @ 2019-05-18 17:49 UTC (permalink / raw) To: syzbot Cc: andreyknvl, chunkeey, chunkeey, davem, kvalo, linux-kernel, linux-usb, linux-wireless, netdev, oneukum, syzkaller-bugs On Sat, 18 May 2019, syzbot wrote: > Hello, > > syzbot has tested the proposed patch but the reproducer still triggered > crash: > KASAN: use-after-free Read in usb_driver_release_interface > > usb 1-1: Loading firmware file isl3887usb > usb 1-1: Direct firmware load for isl3887usb failed with error -2 > usb 1-1: Firmware not found. > p54usb 1-1:0.143: failed to initialize device (-2) > ================================================================== > BUG: KASAN: use-after-free in usb_driver_release_interface+0x16b/0x190 > drivers/usb/core/driver.c:584 > Read of size 8 at addr ffff88808fc31218 by task kworker/0:1/12 Now the bad access is in a different place. That's a good sign. In this case it indicates that although udev is still hanging around, intf has already been freed. We really should acquire a reference to it instead. Alan Stern #syz test: https://github.com/google/kasan.git usb-fuzzer drivers/net/wireless/intersil/p54/p54usb.c | 43 ++++++++++++----------------- 1 file changed, 18 insertions(+), 25 deletions(-) Index: usb-devel/drivers/net/wireless/intersil/p54/p54usb.c =================================================================== --- usb-devel.orig/drivers/net/wireless/intersil/p54/p54usb.c +++ usb-devel/drivers/net/wireless/intersil/p54/p54usb.c @@ -33,6 +33,8 @@ MODULE_ALIAS("prism54usb"); MODULE_FIRMWARE("isl3886usb"); MODULE_FIRMWARE("isl3887usb"); +static struct usb_driver p54u_driver; + /* * Note: * @@ -921,9 +923,9 @@ static void p54u_load_firmware_cb(const { struct p54u_priv *priv = context; struct usb_device *udev = priv->udev; + struct usb_interface *intf = priv->intf; int err; - complete(&priv->fw_wait_load); if (firmware) { priv->fw = firmware; err = p54u_start_ops(priv); @@ -932,26 +934,22 @@ static void p54u_load_firmware_cb(const dev_err(&udev->dev, "Firmware not found.\n"); } - if (err) { - struct device *parent = priv->udev->dev.parent; - - dev_err(&udev->dev, "failed to initialize device (%d)\n", err); - - if (parent) - device_lock(parent); + complete(&priv->fw_wait_load); + /* + * At this point p54u_disconnect may have already freed + * the "priv" context. Do not use it anymore! + */ + priv = NULL; - device_release_driver(&udev->dev); - /* - * At this point p54u_disconnect has already freed - * the "priv" context. Do not use it anymore! - */ - priv = NULL; + if (err) { + dev_err(&intf->dev, "failed to initialize device (%d)\n", err); - if (parent) - device_unlock(parent); + usb_lock_device(udev); + usb_driver_release_interface(&p54u_driver, intf); + usb_unlock_device(udev); } - usb_put_dev(udev); + usb_put_intf(intf); } static int p54u_load_firmware(struct ieee80211_hw *dev, @@ -972,14 +970,14 @@ static int p54u_load_firmware(struct iee dev_info(&priv->udev->dev, "Loading firmware file %s\n", p54u_fwlist[i].fw); - usb_get_dev(udev); + usb_get_intf(intf); err = request_firmware_nowait(THIS_MODULE, 1, p54u_fwlist[i].fw, device, GFP_KERNEL, priv, p54u_load_firmware_cb); if (err) { dev_err(&priv->udev->dev, "(p54usb) cannot load firmware %s " "(%d)!\n", p54u_fwlist[i].fw, err); - usb_put_dev(udev); + usb_put_intf(intf); } return err; @@ -1011,8 +1009,6 @@ static int p54u_probe(struct usb_interfa skb_queue_head_init(&priv->rx_queue); init_usb_anchor(&priv->submitted); - usb_get_dev(udev); - /* really lazy and simple way of figuring out if we're a 3887 */ /* TODO: should just stick the identification in the device table */ i = intf->altsetting->desc.bNumEndpoints; @@ -1053,10 +1049,8 @@ static int p54u_probe(struct usb_interfa priv->upload_fw = p54u_upload_firmware_net2280; } err = p54u_load_firmware(dev, intf); - if (err) { - usb_put_dev(udev); + if (err) p54_free_common(dev); - } return err; } @@ -1072,7 +1066,6 @@ static void p54u_disconnect(struct usb_i wait_for_completion(&priv->fw_wait_load); p54_unregister_common(dev); - usb_put_dev(interface_to_usbdev(intf)); release_firmware(priv->fw); p54_free_common(dev); } ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb 2019-05-18 17:49 ` Alan Stern @ 2019-05-18 18:31 ` syzbot 2019-05-18 20:11 ` Christian Lamparter 1 sibling, 0 replies; 21+ messages in thread From: syzbot @ 2019-05-18 18:31 UTC (permalink / raw) To: andreyknvl, chunkeey, chunkeey, davem, kvalo, linux-kernel, linux-usb, linux-wireless, netdev, oneukum, stern, syzkaller-bugs Hello, syzbot has tested the proposed patch and the reproducer did not trigger crash: Reported-and-tested-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com Tested on: commit: 43151d6c usb-fuzzer: main usb gadget fuzzer driver git tree: https://github.com/google/kasan.git usb-fuzzer kernel config: https://syzkaller.appspot.com/x/.config?x=4183eeef650d1234 compiler: gcc (GCC) 9.0.0 20181231 (experimental) patch: https://syzkaller.appspot.com/x/patch.diff?x=17e42018a00000 Note: testing is done by a robot and is best-effort only. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: KASAN: use-after-free Read in p54u_load_firmware_cb 2019-05-18 17:49 ` Alan Stern 2019-05-18 18:31 ` syzbot @ 2019-05-18 20:11 ` Christian Lamparter 1 sibling, 0 replies; 21+ messages in thread From: Christian Lamparter @ 2019-05-18 20:11 UTC (permalink / raw) To: Alan Stern Cc: syzbot, andreyknvl, chunkeey, davem, kvalo, linux-kernel, linux-usb, linux-wireless, netdev, oneukum, syzkaller-bugs Hello, On Saturday, May 18, 2019 7:49:49 PM CEST you wrote: > On Sat, 18 May 2019, syzbot wrote: > > > > syzbot has tested the proposed patch but the reproducer still triggered > > crash: > > KASAN: use-after-free Read in usb_driver_release_interface > > > > usb 1-1: Loading firmware file isl3887usb > > usb 1-1: Direct firmware load for isl3887usb failed with error -2 > > usb 1-1: Firmware not found. > > p54usb 1-1:0.143: failed to initialize device (-2) > > ================================================================== > > BUG: KASAN: use-after-free in usb_driver_release_interface+0x16b/0x190 > > drivers/usb/core/driver.c:584 > > Read of size 8 at addr ffff88808fc31218 by task kworker/0:1/12 > > Now the bad access is in a different place. That's a good sign. > In this case it indicates that although udev is still hanging around, > intf has already been freed. We really should acquire a reference to > it instead. > > Alan Stern Thanks. I can confirm that it works with the real ISL3887 hardware as well. Can you please spin up a patch or how should this be continued? Cheers, Christian > drivers/net/wireless/intersil/p54/p54usb.c | 43 ++++++++++++----------------- > 1 file changed, 18 insertions(+), 25 deletions(-) > > Index: usb-devel/drivers/net/wireless/intersil/p54/p54usb.c > =================================================================== > --- usb-devel.orig/drivers/net/wireless/intersil/p54/p54usb.c > +++ usb-devel/drivers/net/wireless/intersil/p54/p54usb.c > @@ -33,6 +33,8 @@ MODULE_ALIAS("prism54usb"); > MODULE_FIRMWARE("isl3886usb"); > MODULE_FIRMWARE("isl3887usb"); > > +static struct usb_driver p54u_driver; > + > /* > * Note: > * > @@ -921,9 +923,9 @@ static void p54u_load_firmware_cb(const > { > struct p54u_priv *priv = context; > struct usb_device *udev = priv->udev; > + struct usb_interface *intf = priv->intf; > int err; > > - complete(&priv->fw_wait_load); > if (firmware) { > priv->fw = firmware; > err = p54u_start_ops(priv); > @@ -932,26 +934,22 @@ static void p54u_load_firmware_cb(const > dev_err(&udev->dev, "Firmware not found.\n"); > } > > - if (err) { > - struct device *parent = priv->udev->dev.parent; > - > - dev_err(&udev->dev, "failed to initialize device (%d)\n", err); > - > - if (parent) > - device_lock(parent); > + complete(&priv->fw_wait_load); > + /* > + * At this point p54u_disconnect may have already freed > + * the "priv" context. Do not use it anymore! > + */ > + priv = NULL; > > - device_release_driver(&udev->dev); > - /* > - * At this point p54u_disconnect has already freed > - * the "priv" context. Do not use it anymore! > - */ > - priv = NULL; > + if (err) { > + dev_err(&intf->dev, "failed to initialize device (%d)\n", err); > > - if (parent) > - device_unlock(parent); > + usb_lock_device(udev); > + usb_driver_release_interface(&p54u_driver, intf); > + usb_unlock_device(udev); > } > > - usb_put_dev(udev); > + usb_put_intf(intf); > } > > static int p54u_load_firmware(struct ieee80211_hw *dev, > @@ -972,14 +970,14 @@ static int p54u_load_firmware(struct iee > dev_info(&priv->udev->dev, "Loading firmware file %s\n", > p54u_fwlist[i].fw); > > - usb_get_dev(udev); > + usb_get_intf(intf); > err = request_firmware_nowait(THIS_MODULE, 1, p54u_fwlist[i].fw, > device, GFP_KERNEL, priv, > p54u_load_firmware_cb); > if (err) { > dev_err(&priv->udev->dev, "(p54usb) cannot load firmware %s " > "(%d)!\n", p54u_fwlist[i].fw, err); > - usb_put_dev(udev); > + usb_put_intf(intf); > } > > return err; > @@ -1011,8 +1009,6 @@ static int p54u_probe(struct usb_interfa > skb_queue_head_init(&priv->rx_queue); > init_usb_anchor(&priv->submitted); > > - usb_get_dev(udev); > - > /* really lazy and simple way of figuring out if we're a 3887 */ > /* TODO: should just stick the identification in the device table */ > i = intf->altsetting->desc.bNumEndpoints; > @@ -1053,10 +1049,8 @@ static int p54u_probe(struct usb_interfa > priv->upload_fw = p54u_upload_firmware_net2280; > } > err = p54u_load_firmware(dev, intf); > - if (err) { > - usb_put_dev(udev); > + if (err) > p54_free_common(dev); > - } > return err; > } > > @@ -1072,7 +1066,6 @@ static void p54u_disconnect(struct usb_i > wait_for_completion(&priv->fw_wait_load); > p54_unregister_common(dev); > > - usb_put_dev(interface_to_usbdev(intf)); > release_firmware(priv->fw); > p54_free_common(dev); > } > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH] network: wireless: p54u: Fix race between disconnect and firmware loading 2019-05-17 19:21 ` Christian Lamparter 2019-05-17 20:46 ` Alan Stern @ 2019-05-20 14:44 ` Alan Stern 2019-05-24 21:19 ` Christian Lamparter ` (2 more replies) 1 sibling, 3 replies; 21+ messages in thread From: Alan Stern @ 2019-05-20 14:44 UTC (permalink / raw) To: Christian Lamparter Cc: syzbot, kvalo, davem, andreyknvl, syzkaller-bugs, Kernel development list, USB list, linux-wireless, netdev The syzbot fuzzer found a bug in the p54 USB wireless driver. The issue involves a race between disconnect and the firmware-loader callback routine, and it has several aspects. One big problem is that when the firmware can't be loaded, the callback routine tries to unbind the driver from the USB _device_ (by calling device_release_driver) instead of from the USB _interface_ to which it is actually bound (by calling usb_driver_release_interface). The race involves access to the private data structure. The driver's disconnect handler waits for a completion that is signalled by the firmware-loader callback routine. As soon as the completion is signalled, you have to assume that the private data structure may have been deallocated by the disconnect handler -- even if the firmware was loaded without errors. However, the callback routine does access the private data several times after that point. Another problem is that, in order to ensure that the USB device structure hasn't been freed when the callback routine runs, the driver takes a reference to it. This isn't good enough any more, because now that the callback routine calls usb_driver_release_interface, it has to ensure that the interface structure hasn't been freed. Finally, the driver takes an unnecessary reference to the USB device structure in the probe function and drops the reference in the disconnect handler. This extra reference doesn't accomplish anything, because the USB core already guarantees that a device structure won't be deallocated while a driver is still bound to any of its interfaces. To fix these problems, this patch makes the following changes: Call usb_driver_release_interface() rather than device_release_driver(). Don't signal the completion until after the important information has been copied out of the private data structure, and don't refer to the private data at all thereafter. Lock udev (the interface's parent) before unbinding the driver instead of locking udev->parent. During the firmware loading process, take a reference to the USB interface instead of the USB device. Don't take an unnecessary reference to the device during probe (and then don't drop it during disconnect). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com CC: <stable@vger.kernel.org> --- [as1899] drivers/net/wireless/intersil/p54/p54usb.c | 43 ++++++++++++----------------- 1 file changed, 18 insertions(+), 25 deletions(-) Index: usb-devel/drivers/net/wireless/intersil/p54/p54usb.c =================================================================== --- usb-devel.orig/drivers/net/wireless/intersil/p54/p54usb.c +++ usb-devel/drivers/net/wireless/intersil/p54/p54usb.c @@ -33,6 +33,8 @@ MODULE_ALIAS("prism54usb"); MODULE_FIRMWARE("isl3886usb"); MODULE_FIRMWARE("isl3887usb"); +static struct usb_driver p54u_driver; + /* * Note: * @@ -921,9 +923,9 @@ static void p54u_load_firmware_cb(const { struct p54u_priv *priv = context; struct usb_device *udev = priv->udev; + struct usb_interface *intf = priv->intf; int err; - complete(&priv->fw_wait_load); if (firmware) { priv->fw = firmware; err = p54u_start_ops(priv); @@ -932,26 +934,22 @@ static void p54u_load_firmware_cb(const dev_err(&udev->dev, "Firmware not found.\n"); } - if (err) { - struct device *parent = priv->udev->dev.parent; - - dev_err(&udev->dev, "failed to initialize device (%d)\n", err); - - if (parent) - device_lock(parent); + complete(&priv->fw_wait_load); + /* + * At this point p54u_disconnect may have already freed + * the "priv" context. Do not use it anymore! + */ + priv = NULL; - device_release_driver(&udev->dev); - /* - * At this point p54u_disconnect has already freed - * the "priv" context. Do not use it anymore! - */ - priv = NULL; + if (err) { + dev_err(&intf->dev, "failed to initialize device (%d)\n", err); - if (parent) - device_unlock(parent); + usb_lock_device(udev); + usb_driver_release_interface(&p54u_driver, intf); + usb_unlock_device(udev); } - usb_put_dev(udev); + usb_put_intf(intf); } static int p54u_load_firmware(struct ieee80211_hw *dev, @@ -972,14 +970,14 @@ static int p54u_load_firmware(struct iee dev_info(&priv->udev->dev, "Loading firmware file %s\n", p54u_fwlist[i].fw); - usb_get_dev(udev); + usb_get_intf(intf); err = request_firmware_nowait(THIS_MODULE, 1, p54u_fwlist[i].fw, device, GFP_KERNEL, priv, p54u_load_firmware_cb); if (err) { dev_err(&priv->udev->dev, "(p54usb) cannot load firmware %s " "(%d)!\n", p54u_fwlist[i].fw, err); - usb_put_dev(udev); + usb_put_intf(intf); } return err; @@ -1011,8 +1009,6 @@ static int p54u_probe(struct usb_interfa skb_queue_head_init(&priv->rx_queue); init_usb_anchor(&priv->submitted); - usb_get_dev(udev); - /* really lazy and simple way of figuring out if we're a 3887 */ /* TODO: should just stick the identification in the device table */ i = intf->altsetting->desc.bNumEndpoints; @@ -1053,10 +1049,8 @@ static int p54u_probe(struct usb_interfa priv->upload_fw = p54u_upload_firmware_net2280; } err = p54u_load_firmware(dev, intf); - if (err) { - usb_put_dev(udev); + if (err) p54_free_common(dev); - } return err; } @@ -1072,7 +1066,6 @@ static void p54u_disconnect(struct usb_i wait_for_completion(&priv->fw_wait_load); p54_unregister_common(dev); - usb_put_dev(interface_to_usbdev(intf)); release_firmware(priv->fw); p54_free_common(dev); } ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] network: wireless: p54u: Fix race between disconnect and firmware loading 2019-05-20 14:44 ` [PATCH] network: wireless: p54u: Fix race between disconnect and firmware loading Alan Stern @ 2019-05-24 21:19 ` Christian Lamparter 2019-05-28 12:11 ` Kalle Valo 2019-06-25 4:43 ` [PATCH] p54usb: " Kalle Valo 2 siblings, 0 replies; 21+ messages in thread From: Christian Lamparter @ 2019-05-24 21:19 UTC (permalink / raw) To: Alan Stern Cc: syzbot, kvalo, davem, andreyknvl, syzkaller-bugs, Kernel development list, USB list, linux-wireless, netdev On Monday, May 20, 2019 4:44:21 PM CEST Alan Stern wrote: > The syzbot fuzzer found a bug in the p54 USB wireless driver. The > issue involves a race between disconnect and the firmware-loader > callback routine, and it has several aspects. > > One big problem is that when the firmware can't be loaded, the > callback routine tries to unbind the driver from the USB _device_ (by > calling device_release_driver) instead of from the USB _interface_ to > which it is actually bound (by calling usb_driver_release_interface). > > The race involves access to the private data structure. The driver's > disconnect handler waits for a completion that is signalled by the > firmware-loader callback routine. As soon as the completion is > signalled, you have to assume that the private data structure may have > been deallocated by the disconnect handler -- even if the firmware was > loaded without errors. However, the callback routine does access the > private data several times after that point. > > Another problem is that, in order to ensure that the USB device > structure hasn't been freed when the callback routine runs, the driver > takes a reference to it. This isn't good enough any more, because now > that the callback routine calls usb_driver_release_interface, it has > to ensure that the interface structure hasn't been freed. > > Finally, the driver takes an unnecessary reference to the USB device > structure in the probe function and drops the reference in the > disconnect handler. This extra reference doesn't accomplish anything, > because the USB core already guarantees that a device structure won't > be deallocated while a driver is still bound to any of its interfaces. > > To fix these problems, this patch makes the following changes: > > Call usb_driver_release_interface() rather than > device_release_driver(). > > Don't signal the completion until after the important > information has been copied out of the private data structure, > and don't refer to the private data at all thereafter. > > Lock udev (the interface's parent) before unbinding the driver > instead of locking udev->parent. > > During the firmware loading process, take a reference to the > USB interface instead of the USB device. > > Don't take an unnecessary reference to the device during probe > (and then don't drop it during disconnect). > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu> > Reported-and-tested-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com > CC: <stable@vger.kernel.org> Finally I'm at home where I have the device. Did some test with replugging and module unloading, all seems fine. Thanks! Acked-by: Christian Lamparter <chunkeey@gmail.com> ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] network: wireless: p54u: Fix race between disconnect and firmware loading 2019-05-20 14:44 ` [PATCH] network: wireless: p54u: Fix race between disconnect and firmware loading Alan Stern 2019-05-24 21:19 ` Christian Lamparter @ 2019-05-28 12:11 ` Kalle Valo 2019-05-28 14:17 ` Alan Stern 2019-06-25 4:43 ` [PATCH] p54usb: " Kalle Valo 2 siblings, 1 reply; 21+ messages in thread From: Kalle Valo @ 2019-05-28 12:11 UTC (permalink / raw) To: Alan Stern Cc: Christian Lamparter, syzbot, davem, andreyknvl, syzkaller-bugs, Kernel development list, USB list, linux-wireless, netdev Alan Stern <stern@rowland.harvard.edu> writes: > The syzbot fuzzer found a bug in the p54 USB wireless driver. The > issue involves a race between disconnect and the firmware-loader > callback routine, and it has several aspects. > > One big problem is that when the firmware can't be loaded, the > callback routine tries to unbind the driver from the USB _device_ (by > calling device_release_driver) instead of from the USB _interface_ to > which it is actually bound (by calling usb_driver_release_interface). > > The race involves access to the private data structure. The driver's > disconnect handler waits for a completion that is signalled by the > firmware-loader callback routine. As soon as the completion is > signalled, you have to assume that the private data structure may have > been deallocated by the disconnect handler -- even if the firmware was > loaded without errors. However, the callback routine does access the > private data several times after that point. > > Another problem is that, in order to ensure that the USB device > structure hasn't been freed when the callback routine runs, the driver > takes a reference to it. This isn't good enough any more, because now > that the callback routine calls usb_driver_release_interface, it has > to ensure that the interface structure hasn't been freed. > > Finally, the driver takes an unnecessary reference to the USB device > structure in the probe function and drops the reference in the > disconnect handler. This extra reference doesn't accomplish anything, > because the USB core already guarantees that a device structure won't > be deallocated while a driver is still bound to any of its interfaces. > > To fix these problems, this patch makes the following changes: > > Call usb_driver_release_interface() rather than > device_release_driver(). > > Don't signal the completion until after the important > information has been copied out of the private data structure, > and don't refer to the private data at all thereafter. > > Lock udev (the interface's parent) before unbinding the driver > instead of locking udev->parent. > > During the firmware loading process, take a reference to the > USB interface instead of the USB device. > > Don't take an unnecessary reference to the device during probe > (and then don't drop it during disconnect). > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu> > Reported-and-tested-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com > CC: <stable@vger.kernel.org> > > --- > > > [as1899] > > > drivers/net/wireless/intersil/p54/p54usb.c | 43 ++++++++++++----------------- > 1 file changed, 18 insertions(+), 25 deletions(-) The correct prefix is "p54:", but I can fix that during commit. > Index: usb-devel/drivers/net/wireless/intersil/p54/p54usb.c > =================================================================== > --- usb-devel.orig/drivers/net/wireless/intersil/p54/p54usb.c > +++ usb-devel/drivers/net/wireless/intersil/p54/p54usb.c > @@ -33,6 +33,8 @@ MODULE_ALIAS("prism54usb"); > MODULE_FIRMWARE("isl3886usb"); > MODULE_FIRMWARE("isl3887usb"); > > +static struct usb_driver p54u_driver; How is it safe to use static variables from a wireless driver? For example, what if there are two p54 usb devices on the host? How do we avoid a race in that case? -- Kalle Valo ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] network: wireless: p54u: Fix race between disconnect and firmware loading 2019-05-28 12:11 ` Kalle Valo @ 2019-05-28 14:17 ` Alan Stern 2019-05-28 14:29 ` Kalle Valo 0 siblings, 1 reply; 21+ messages in thread From: Alan Stern @ 2019-05-28 14:17 UTC (permalink / raw) To: Kalle Valo Cc: Christian Lamparter, syzbot, davem, andreyknvl, syzkaller-bugs, Kernel development list, USB list, linux-wireless, netdev On Tue, 28 May 2019, Kalle Valo wrote: > The correct prefix is "p54:", but I can fix that during commit. Oh, okay, thanks. > > Index: usb-devel/drivers/net/wireless/intersil/p54/p54usb.c > > =================================================================== > > --- usb-devel.orig/drivers/net/wireless/intersil/p54/p54usb.c > > +++ usb-devel/drivers/net/wireless/intersil/p54/p54usb.c > > @@ -33,6 +33,8 @@ MODULE_ALIAS("prism54usb"); > > MODULE_FIRMWARE("isl3886usb"); > > MODULE_FIRMWARE("isl3887usb"); > > > > +static struct usb_driver p54u_driver; > > How is it safe to use static variables from a wireless driver? For > example, what if there are two p54 usb devices on the host? How do we > avoid a race in that case? There is no race. This structure is not per-device; it refers only to the driver. In fact, the line above is only a forward declaration -- the actual definition of p54u_driver was already in the source file. Alan Stern ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] network: wireless: p54u: Fix race between disconnect and firmware loading 2019-05-28 14:17 ` Alan Stern @ 2019-05-28 14:29 ` Kalle Valo 0 siblings, 0 replies; 21+ messages in thread From: Kalle Valo @ 2019-05-28 14:29 UTC (permalink / raw) To: Alan Stern Cc: Christian Lamparter, syzbot, davem, andreyknvl, syzkaller-bugs, Kernel development list, USB list, linux-wireless, netdev Alan Stern <stern@rowland.harvard.edu> writes: > On Tue, 28 May 2019, Kalle Valo wrote: > >> The correct prefix is "p54:", but I can fix that during commit. > > Oh, okay, thanks. > >> > Index: usb-devel/drivers/net/wireless/intersil/p54/p54usb.c >> > =================================================================== >> > --- usb-devel.orig/drivers/net/wireless/intersil/p54/p54usb.c >> > +++ usb-devel/drivers/net/wireless/intersil/p54/p54usb.c >> > @@ -33,6 +33,8 @@ MODULE_ALIAS("prism54usb"); >> > MODULE_FIRMWARE("isl3886usb"); >> > MODULE_FIRMWARE("isl3887usb"); >> > >> > +static struct usb_driver p54u_driver; >> >> How is it safe to use static variables from a wireless driver? For >> example, what if there are two p54 usb devices on the host? How do we >> avoid a race in that case? > > There is no race. This structure is not per-device; it refers only to > the driver. In fact, the line above is only a forward declaration -- > the actual definition of p54u_driver was already in the source file. Ah, I missed that. Thanks! -- Kalle Valo ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH] p54usb: Fix race between disconnect and firmware loading 2019-05-20 14:44 ` [PATCH] network: wireless: p54u: Fix race between disconnect and firmware loading Alan Stern 2019-05-24 21:19 ` Christian Lamparter 2019-05-28 12:11 ` Kalle Valo @ 2019-06-25 4:43 ` Kalle Valo 2 siblings, 0 replies; 21+ messages in thread From: Kalle Valo @ 2019-06-25 4:43 UTC (permalink / raw) To: Alan Stern Cc: Christian Lamparter, syzbot, davem, andreyknvl, syzkaller-bugs, Kernel development list, USB list, linux-wireless, netdev Alan Stern <stern@rowland.harvard.edu> wrote: > The syzbot fuzzer found a bug in the p54 USB wireless driver. The > issue involves a race between disconnect and the firmware-loader > callback routine, and it has several aspects. > > One big problem is that when the firmware can't be loaded, the > callback routine tries to unbind the driver from the USB _device_ (by > calling device_release_driver) instead of from the USB _interface_ to > which it is actually bound (by calling usb_driver_release_interface). > > The race involves access to the private data structure. The driver's > disconnect handler waits for a completion that is signalled by the > firmware-loader callback routine. As soon as the completion is > signalled, you have to assume that the private data structure may have > been deallocated by the disconnect handler -- even if the firmware was > loaded without errors. However, the callback routine does access the > private data several times after that point. > > Another problem is that, in order to ensure that the USB device > structure hasn't been freed when the callback routine runs, the driver > takes a reference to it. This isn't good enough any more, because now > that the callback routine calls usb_driver_release_interface, it has > to ensure that the interface structure hasn't been freed. > > Finally, the driver takes an unnecessary reference to the USB device > structure in the probe function and drops the reference in the > disconnect handler. This extra reference doesn't accomplish anything, > because the USB core already guarantees that a device structure won't > be deallocated while a driver is still bound to any of its interfaces. > > To fix these problems, this patch makes the following changes: > > Call usb_driver_release_interface() rather than > device_release_driver(). > > Don't signal the completion until after the important > information has been copied out of the private data structure, > and don't refer to the private data at all thereafter. > > Lock udev (the interface's parent) before unbinding the driver > instead of locking udev->parent. > > During the firmware loading process, take a reference to the > USB interface instead of the USB device. > > Don't take an unnecessary reference to the device during probe > (and then don't drop it during disconnect). > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu> > Reported-and-tested-by: syzbot+200d4bb11b23d929335f@syzkaller.appspotmail.com > CC: <stable@vger.kernel.org> > Acked-by: Christian Lamparter <chunkeey@gmail.com> Patch applied to wireless-drivers-next.git, thanks. 6e41e2257f10 p54usb: Fix race between disconnect and firmware loading -- https://patchwork.kernel.org/patch/10951527/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2019-06-25 4:43 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-05-06 11:16 KASAN: use-after-free Read in p54u_load_firmware_cb syzbot 2019-05-13 10:23 ` syzbot 2019-05-13 13:28 ` Oliver Neukum 2019-05-17 19:21 ` Christian Lamparter 2019-05-17 20:46 ` Alan Stern 2019-05-17 21:01 ` syzbot 2019-05-18 15:13 ` Alan Stern 2019-05-18 15:50 ` syzbot 2019-05-18 16:32 ` Alan Stern 2019-05-18 16:50 ` syzbot 2019-05-18 17:01 ` Alan Stern 2019-05-18 17:36 ` syzbot 2019-05-18 17:49 ` Alan Stern 2019-05-18 18:31 ` syzbot 2019-05-18 20:11 ` Christian Lamparter 2019-05-20 14:44 ` [PATCH] network: wireless: p54u: Fix race between disconnect and firmware loading Alan Stern 2019-05-24 21:19 ` Christian Lamparter 2019-05-28 12:11 ` Kalle Valo 2019-05-28 14:17 ` Alan Stern 2019-05-28 14:29 ` Kalle Valo 2019-06-25 4:43 ` [PATCH] p54usb: " Kalle Valo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).