Re: [PATCH 00/14] ARM: move lpc32xx and dove to multiplatform
On Thu, Aug 1, 2019 at 12:53 AM Russell King - ARM Linux admin wrote: > > On Wed, Jul 31, 2019 at 09:56:42PM +0200, Arnd Bergmann wrote: > > For dove, the patches are basically what I had proposed back in > > 2015 when all other ARMv6/ARMv7 machines became part of a single > > kernel build. I don't know what the state is mach-dove support is, > > compared to the DT based support in mach-mvebu for the same > > hardware. If they are functionally the same, we could also just > > remove mach-dove rather than applying my patches. > > Well, the good news is that I'm down to a small board support file > for the Dove Cubox now - but the bad news is, that there's still a > board support file necessary to support everything the Dove SoC has > to offer. > > Even for a DT based Dove Cubox, I'm still using mach-dove, but it > may be possible to drop most of mach-dove now. Without spending a > lot of time digging through it, it's impossible to really know. Ok, so we won't remove it then, but I'd like to merge my patches to at least get away from the special case of requiring a separate kernel image for it. Can you try if applying patches 12 and 14 from my series causes problems for you? (it may be easier to apply the entire set or pull from [1] to avoid rebase conflicts). Arnd [1] kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git mach-cleanup-5.4
[PATCH] HID: usbhid: Use GFP_KERNEL instead of GFP_ATOMIC when applicable
There is no need to use GFP_ATOMIC when calling 'usb_alloc_coherent()' here. These calls are done from probe functions and using GFP_KERNEL should be safe. The memory itself is used within some interrupts, but it is not a problem, once it has been allocated. Signed-off-by: Christophe JAILLET --- drivers/hid/usbhid/usbkbd.c | 4 ++-- drivers/hid/usbhid/usbmouse.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c index d5b7a696a68c..63e8ef8beb45 100644 --- a/drivers/hid/usbhid/usbkbd.c +++ b/drivers/hid/usbhid/usbkbd.c @@ -239,11 +239,11 @@ static int usb_kbd_alloc_mem(struct usb_device *dev, struct usb_kbd *kbd) return -1; if (!(kbd->led = usb_alloc_urb(0, GFP_KERNEL))) return -1; - if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma))) + if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_KERNEL, &kbd->new_dma))) return -1; if (!(kbd->cr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL))) return -1; - if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_ATOMIC, &kbd->leds_dma))) + if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_KERNEL, &kbd->leds_dma))) return -1; return 0; diff --git a/drivers/hid/usbhid/usbmouse.c b/drivers/hid/usbhid/usbmouse.c index 073127e65ac1..c89332017d5d 100644 --- a/drivers/hid/usbhid/usbmouse.c +++ b/drivers/hid/usbhid/usbmouse.c @@ -130,7 +130,7 @@ static int usb_mouse_probe(struct usb_interface *intf, const struct usb_device_i if (!mouse || !input_dev) goto fail1; - mouse->data = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &mouse->data_dma); + mouse->data = usb_alloc_coherent(dev, 8, GFP_KERNEL, &mouse->data_dma); if (!mouse->data) goto fail1; -- 2.20.1
[PATCH] usb: typec: ucsi: ccg: Fix uninitilized symbol error
Fix smatch error:
drivers/usb/typec/ucsi/ucsi_ccg.c:975 ccg_fw_update() error: uninitialized
symbol 'err'.
Fixes: 5c9ae5a87573 ("usb: typec: ucsi: ccg: add firmware flashing support")
Cc: sta...@vger.kernel.org
Reported-by: kbuild test robot
Signed-off-by: Heikki Krogerus
---
drivers/usb/typec/ucsi/ucsi_ccg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/typec/ucsi/ucsi_ccg.c
b/drivers/usb/typec/ucsi/ucsi_ccg.c
index f7a79a23ebed..8e9f8fba55af 100644
--- a/drivers/usb/typec/ucsi/ucsi_ccg.c
+++ b/drivers/usb/typec/ucsi/ucsi_ccg.c
@@ -1018,7 +1018,7 @@ static int do_flash(struct ucsi_ccg *uc, enum
enum_flash_mode mode)
**/
static int ccg_fw_update(struct ucsi_ccg *uc, enum enum_flash_mode flash_mode)
{
- int err;
+ int err = 0;
while (flash_mode != FLASH_NOT_NEEDED) {
err = do_flash(uc, flash_mode);
--
2.20.1
Unhandled fault: imprecise external abort (0x1406) when loading xhci_pci.ko - uPD720202, PEX8605, iMX6Q and linux-4.19.25
Hi everyone, I am trying to get Renesas uPD720202 USB3.0 hub working which is connected PCIe switch (PEX8605); PEX8605 is connected to i.MX6Q through its x1 PCIe Gen2 interface. Running Linux-4.19.25 vanilla kernel with patches from Phytec.de for their Phycore-iMX6Q SOM. We have 2x PEX8605 ports connected to mPCIe slots and 2x WLAN modules (QCA9880) working perfectly. Facing kernel "Unhandled fault: imprecise external abort (0x1406)" when trying to load xhci_pci.ko module for uPD720202. Receiving this fault straight-away when driver trying to setup device. uPD720202 don't have external EEPROM support, so I have to load firmware in chips memory before loading the driver. Sometimes after loading the driver, I see the USB3.0 hub but then doing "lsusb -v" crashes the driver with same above mentioned fault. Tried to disable DMA from kernel configuration but still same result. >From hardware side verified the RESET pins for PEX8605 and uPD720202 chips but no change. Also wanted to read PCIe switch registers using I2C interface but have to figure-out how to do that (saw some patches email from Rajat Jain from 2014 but seems like can't find the patch attachment anywhere on Google). The kernel log is below. Any help or pointers in solving this problem will be much appreciated. [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.19.25-bsp-yocto-i.mx6-pd18.1.1 (br-user@flateef-XPS-13-9360) (gcc version 8.2.0 (Buildroot 2018.11.4-gebef590b)) #3 SMP Wed Jul 31 11:13:06 UTC 2019 [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] OF: fdt: Machine model: PHYTEC phyBOARD-Mira Quad full featured with eMMC [0.00] Memory policy: Data cache writealloc [0.00] cma: Reserved 128 MiB at 0x8600 [0.00] On node 0 totalpages: 524288 [0.00] Normal zone: 1536 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 196608 pages, LIFO batch:63 [0.00] HighMem zone: 327680 pages, LIFO batch:63 [0.00] random: get_random_bytes called from start_kernel+0x88/0x3f8 with crng_init=0 [0.00] percpu: Embedded 16 pages/cpu @(ptrval) s34828 r8192 d22516 u65536 [0.00] pcpu-alloc: s34828 r8192 d22516 u65536 alloc=16*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 522752 [0.00] Kernel command line: console=ttymxc1,115200n8 root=/dev/mmcblk3p2 rootwait rw [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1934476K/2097152K available (8192K kernel code, 357K rwdata, 2464K rodata, 1024K init, 398K bss, 31604K reserved, 131072K cma-reserved, 1178732K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB) [0.00] lowmem : 0xc000 - 0xf000 ( 768 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0x(ptrval) - 0x(ptrval) (9184 kB) [0.00] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) [0.00] .data : 0x(ptrval) - 0x(ptrval) ( 358 kB) [0.00].bss : 0x(ptrval) - 0x(ptrval) ( 399 kB) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] rcu: Hierarchical RCU implementation. [0.00] rcu: RCU event tracing is enabled. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] L2C-310 errata 752271 769419 enabled [0.00] L2C-310 enabling early BRESP for Cortex-A9 [0.00] L2C-310 full line of zeros enabled for Cortex-A9 [0.00] L2C-310 ID prefetch enabled, offset 16 lines [0.00] L2C-310 dynamic clock gating enabled, standby mode enabled [0.00] L2C-310 cache controller enabled, 16 ways, 1024 kB [0.00] L2C-310: CACHE_ID 0x41c7, AUX_CTRL 0x76470001 [0.00] Switching to timer-based delay loop, resolution 333ns [0.15] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 715827882841ns [0.49] clocksource: mxc_timer1: mask: 0x max_cycles: 0x, max_idle_ns: 637086815595 ns [0.002812] Console: colour dummy device 80x30 [0.002873] Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=3) [0.002903] pid_max: default: 32768 minimum: 301 [0.003188] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.003229] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.004259] CPU: Testi
[PATCH] dt-bindings: usb: renesas_gen3: Rename bindings documentation file to reflect IP block
For consistency with the naming of (most) other documentation files for DT
bindings for Renesas IP blocks rename the Renesas USB3.0 peripheral
documentation file from renesas,gen3.txt to renesas,usb3-peri.txt
This refines a recent rename from renesas,gen3.txt to renesas-gen3.txt.
The motivation is to to more accurately reflect the IP block documented in
this file.
Signed-off-by: Simon Horman
---
* Based on v5.3-rc1
---
.../devicetree/bindings/usb/{renesas,usb3.txt => renesas,usb3-peri.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/usb/{renesas,usb3.txt =>
renesas,usb3-peri.txt} (100%)
diff --git a/Documentation/devicetree/bindings/usb/renesas,usb3.txt
b/Documentation/devicetree/bindings/usb/renesas,usb3-peri.txt
similarity index 100%
rename from Documentation/devicetree/bindings/usb/renesas,usb3.txt
rename to Documentation/devicetree/bindings/usb/renesas,usb3-peri.txt
--
2.11.0
Re: [PATCH v2 2/2] dt-bindings: usb: renesas_gen3: Rename bindings documentation file
On Mon, Jul 29, 2019 at 08:25:24AM +, Yoshihiro Shimoda wrote: > Hi Simon-san, > > > From: Simon Horman, Sent: Monday, July 29, 2019 5:15 PM > > > > > > > Unfortunately the previous version has already made it into usb-next > > > > > > 23c46801d14cb647 dt-bindings: usb: renesas_gen3: Rename bindings > > > > > > documentation file > > > > > > > > > > Ok, I guess we should go with that version. > > > > > > > > So can you resend this series based on 5.3-rc1 so I know what to apply? > > > > > > Since your usb-testing branch already has it which is merged from > > > Felipe's usb-next branch, > > > I don't think Simon has to resend this series. > > > > > > https://www.spinics.net/lists/linux-usb/msg182103.html > > > > Thanks and sorry for the confusion. > > > > In v5.2-rc1 we had: > > > > devicetree/bindings/usb/renesas_usb3.txt > > devicetree/bindings/usb/renesas_usbhs.txt > > > > > > In v5.3-rc1 we have: > > > > devicetree/bindings/usb/renesas,usb3.txt > > devicetree/bindings/usb/renesas,usbhs.txt > > > > Which reflects v1 of this patchset. And I think this is an improvement. > > > > Shimoda-san, can you let me know if you would like me to rebase v2 > > on v5.3-rc1? That would would give us: > > > > devicetree/bindings/usb/renesas,usb3-peri.txt > > devicetree/bindings/usb/renesas,usbhs.txt [unchanged] > > Thank you for the detail. I would like you to rebase v2 like that, if > possible. Thanks, I have posted this as: [PATCH] dt-bindings: usb: renesas_gen3: Rename bindings documentation file to reflect IP block
Re: [PATCH] dt-bindings: usb: renesas_gen3: Rename bindings documentation file to reflect IP block
On Thu, Aug 1, 2019 at 11:13 AM Simon Horman wrote:
> For consistency with the naming of (most) other documentation files for DT
> bindings for Renesas IP blocks rename the Renesas USB3.0 peripheral
> documentation file from renesas,gen3.txt to renesas,usb3-peri.txt
from renesas,usb3.txt
> This refines a recent rename from renesas,gen3.txt to renesas-gen3.txt.
Actually it was renamed from renesas_usb3.txt to renesas,usb3.txt.
> The motivation is to to more accurately reflect the IP block documented in
double to
> this file.
>
> Signed-off-by: Simon Horman
With the above fixed:
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] dt-bindings: usb: renesas_gen3: Rename bindings documentation file to reflect IP block
On Thu, Aug 01, 2019 at 11:18:36AM +0200, Geert Uytterhoeven wrote: > On Thu, Aug 1, 2019 at 11:13 AM Simon Horman > wrote: > > For consistency with the naming of (most) other documentation files for DT > > bindings for Renesas IP blocks rename the Renesas USB3.0 peripheral > > documentation file from renesas,gen3.txt to renesas,usb3-peri.txt > > from renesas,usb3.txt > > > This refines a recent rename from renesas,gen3.txt to renesas-gen3.txt. > > Actually it was renamed from renesas_usb3.txt to renesas,usb3.txt. > > > The motivation is to to more accurately reflect the IP block documented in > > double to > > > this file. > > > > Signed-off-by: Simon Horman > > With the above fixed: > Reviewed-by: Geert Uytterhoeven Thanks, I'll fix this up.
Re: [PATCH] HID: usbhid: Use GFP_KERNEL instead of GFP_ATOMIC when applicable
Am 01.08.2019 09:47, schrieb Christophe JAILLET: > There is no need to use GFP_ATOMIC when calling 'usb_alloc_coherent()' > here. These calls are done from probe functions and using GFP_KERNEL should > be safe. > The memory itself is used within some interrupts, but it is not a > problem, once it has been allocated. > > Signed-off-by: Christophe JAILLET > --- > drivers/hid/usbhid/usbkbd.c | 4 ++-- > drivers/hid/usbhid/usbmouse.c | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c > index d5b7a696a68c..63e8ef8beb45 100644 > --- a/drivers/hid/usbhid/usbkbd.c > +++ b/drivers/hid/usbhid/usbkbd.c > @@ -239,11 +239,11 @@ static int usb_kbd_alloc_mem(struct usb_device *dev, > struct usb_kbd *kbd) > return -1; > if (!(kbd->led = usb_alloc_urb(0, GFP_KERNEL))) > return -1; > - if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma))) > + if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_KERNEL, &kbd->new_dma))) > return -1; > if (!(kbd->cr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL))) > return -1; > - if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_ATOMIC, > &kbd->leds_dma))) > + if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_KERNEL, > &kbd->leds_dma))) > return -1; > the kernel style is usually: kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma); if (!kbd->new) return -1; in usbmouse.c this is done, any reason for the change here ? re, wh > return 0; > diff --git a/drivers/hid/usbhid/usbmouse.c b/drivers/hid/usbhid/usbmouse.c > index 073127e65ac1..c89332017d5d 100644 > --- a/drivers/hid/usbhid/usbmouse.c > +++ b/drivers/hid/usbhid/usbmouse.c > @@ -130,7 +130,7 @@ static int usb_mouse_probe(struct usb_interface *intf, > const struct usb_device_i > if (!mouse || !input_dev) > goto fail1; > > - mouse->data = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &mouse->data_dma); > + mouse->data = usb_alloc_coherent(dev, 8, GFP_KERNEL, &mouse->data_dma); > if (!mouse->data) > goto fail1; >
KASAN: use-after-free Read in usb_free_coherent
Hello, syzbot found the following crash on: HEAD commit:7f7867ff 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=13efa03060 kernel config: https://syzkaller.appspot.com/x/.config?x=792eb47789f57810 dashboard link: https://syzkaller.appspot.com/bug?extid=d1fedb1c1fdb07fca507 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+d1fedb1c1fdb07fca...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in usb_free_coherent+0x79/0x80 drivers/usb/core/usb.c:928 Read of size 8 at addr 8881b18599c8 by task syz-executor.4/16007 CPU: 0 PID: 16007 Comm: syz-executor.4 Not tainted 5.3.0-rc2+ #23 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 print_address_description+0x6a/0x32c mm/kasan/report.c:351 __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482 kasan_report+0xe/0x12 mm/kasan/common.c:612 usb_free_coherent+0x79/0x80 drivers/usb/core/usb.c:928 yurex_delete+0x138/0x330 drivers/usb/misc/yurex.c:100 kref_put include/linux/kref.h:65 [inline] yurex_release+0x66/0x90 drivers/usb/misc/yurex.c:392 __fput+0x2d7/0x840 fs/file_table.c:280 task_work_run+0x13f/0x1c0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x1d2/0x200 arch/x86/entry/common.c:163 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline] syscall_return_slowpath arch/x86/entry/common.c:274 [inline] do_syscall_64+0x45f/0x580 arch/x86/entry/common.c:299 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x413511 Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 1b 00 00 c3 48 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01 RSP: 002b:7ffc424ea2e0 EFLAGS: 0293 ORIG_RAX: 0003 RAX: RBX: 0007 RCX: 00413511 RDX: RSI: RDI: 0006 RBP: 0001 R08: 29a2fc22 R09: 29a2fc26 R10: 7ffc424ea3c0 R11: 0293 R12: 0075c9a0 R13: 0075c9a0 R14: 00761938 R15: Allocated by task 2776: save_stack+0x1b/0x80 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] __kasan_kmalloc mm/kasan/common.c:487 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460 kmalloc include/linux/slab.h:552 [inline] kzalloc include/linux/slab.h:748 [inline] usb_alloc_dev+0x51/0xf95 drivers/usb/core/usb.c:583 hub_port_connect drivers/usb/core/hub.c:5004 [inline] hub_port_connect_change drivers/usb/core/hub.c:5213 [inline] port_event drivers/usb/core/hub.c:5359 [inline] hub_event+0x15c0/0x3640 drivers/usb/core/hub.c:5441 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269 worker_thread+0x96/0xe20 kernel/workqueue.c:2415 kthread+0x318/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Freed by task 16007: save_stack+0x1b/0x80 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] __kasan_slab_free+0x130/0x180 mm/kasan/common.c:449 slab_free_hook mm/slub.c:1423 [inline] slab_free_freelist_hook mm/slub.c:1470 [inline] slab_free mm/slub.c:3012 [inline] kfree+0xe4/0x2f0 mm/slub.c:3953 device_release+0x71/0x200 drivers/base/core.c:1064 kobject_cleanup lib/kobject.c:693 [inline] kobject_release lib/kobject.c:722 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x171/0x280 lib/kobject.c:739 put_device+0x1b/0x30 drivers/base/core.c:2213 usb_put_dev+0x1f/0x30 drivers/usb/core/usb.c:725 yurex_delete+0x40/0x330 drivers/usb/misc/yurex.c:95 kref_put include/linux/kref.h:65 [inline] yurex_release+0x66/0x90 drivers/usb/misc/yurex.c:392 __fput+0x2d7/0x840 fs/file_table.c:280 task_work_run+0x13f/0x1c0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x1d2/0x200 arch/x86/entry/common.c:163 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline] syscall_return_slowpath arch/x86/entry/common.c:274 [inline] do_syscall_64+0x45f/0x580 arch/x86/entry/common.c:299 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at 8881b1859980 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 72 bytes inside of 2048-byte region [8881b1859980, 8881b185a180) The buggy address belongs to the page: page:ea0006c61600 refcount:1 mapcount:0 mapping:8881da00c000 index:0x0 compound_mapcount: 0 flags: 0x2010200(slab|head) raw: 0201020
Re: KASAN: use-after-free Read in usb_free_coherent
Hi On 01/08/2019 11:38, syzbot wrote: Hello, syzbot found the following crash on: HEAD commit:7f7867ff 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=13efa03060 kernel config: https://syzkaller.appspot.com/x/.config?x=792eb47789f57810 dashboard link: https://syzkaller.appspot.com/bug?extid=d1fedb1c1fdb07fca507 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+d1fedb1c1fdb07fca...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in usb_free_coherent+0x79/0x80 drivers/usb/core/usb.c:928 Read of size 8 at addr 8881b18599c8 by task syz-executor.4/16007 CPU: 0 PID: 16007 Comm: syz-executor.4 Not tainted 5.3.0-rc2+ #23 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 print_address_description+0x6a/0x32c mm/kasan/report.c:351 __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482 kasan_report+0xe/0x12 mm/kasan/common.c:612 usb_free_coherent+0x79/0x80 drivers/usb/core/usb.c:928 yurex_delete+0x138/0x330 drivers/usb/misc/yurex.c:100 kref_put include/linux/kref.h:65 [inline] yurex_release+0x66/0x90 drivers/usb/misc/yurex.c:392 __fput+0x2d7/0x840 fs/file_table.c:280 task_work_run+0x13f/0x1c0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x1d2/0x200 arch/x86/entry/common.c:163 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline] syscall_return_slowpath arch/x86/entry/common.c:274 [inline] do_syscall_64+0x45f/0x580 arch/x86/entry/common.c:299 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x413511 Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 1b 00 00 c3 48 83 ec 08 e8 0a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01 RSP: 002b:7ffc424ea2e0 EFLAGS: 0293 ORIG_RAX: 0003 RAX: RBX: 0007 RCX: 00413511 RDX: RSI: RDI: 0006 RBP: 0001 R08: 29a2fc22 R09: 29a2fc26 R10: 7ffc424ea3c0 R11: 0293 R12: 0075c9a0 R13: 0075c9a0 R14: 00761938 R15: Allocated by task 2776: save_stack+0x1b/0x80 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] __kasan_kmalloc mm/kasan/common.c:487 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460 kmalloc include/linux/slab.h:552 [inline] kzalloc include/linux/slab.h:748 [inline] usb_alloc_dev+0x51/0xf95 drivers/usb/core/usb.c:583 hub_port_connect drivers/usb/core/hub.c:5004 [inline] hub_port_connect_change drivers/usb/core/hub.c:5213 [inline] port_event drivers/usb/core/hub.c:5359 [inline] hub_event+0x15c0/0x3640 drivers/usb/core/hub.c:5441 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269 worker_thread+0x96/0xe20 kernel/workqueue.c:2415 kthread+0x318/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Freed by task 16007: save_stack+0x1b/0x80 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] __kasan_slab_free+0x130/0x180 mm/kasan/common.c:449 slab_free_hook mm/slub.c:1423 [inline] slab_free_freelist_hook mm/slub.c:1470 [inline] slab_free mm/slub.c:3012 [inline] kfree+0xe4/0x2f0 mm/slub.c:3953 device_release+0x71/0x200 drivers/base/core.c:1064 kobject_cleanup lib/kobject.c:693 [inline] kobject_release lib/kobject.c:722 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x171/0x280 lib/kobject.c:739 put_device+0x1b/0x30 drivers/base/core.c:2213 usb_put_dev+0x1f/0x30 drivers/usb/core/usb.c:725 yurex_delete+0x40/0x330 drivers/usb/misc/yurex.c:95 kref_put include/linux/kref.h:65 [inline] yurex_release+0x66/0x90 drivers/usb/misc/yurex.c:392 __fput+0x2d7/0x840 fs/file_table.c:280 task_work_run+0x13f/0x1c0 kernel/task_work.c:113 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop+0x1d2/0x200 arch/x86/entry/common.c:163 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline] syscall_return_slowpath arch/x86/entry/common.c:274 [inline] do_syscall_64+0x45f/0x580 arch/x86/entry/common.c:299 entry_SYSCALL_64_after_hwframe+0x49/0xbe Looks like the yurex_delete() drops the ref count on the dev->udev way early in the function and then later tries to see if there are any other buffers associated with it worth releasing. So, I am guessing moving the usb_put_dev(), after we have finished all that migh
Re: [PATCH v2] usb: typec: tcpm: Add NULL check before dereferencing config
On 2019-07-31 6:47 p.m., Douglas Gilbert wrote:
On 2019-07-24 4:38 p.m., Guenter Roeck wrote:
When instantiating tcpm on an NXP OM 13588 board with NXP PTN5110,
the following crash is seen when writing into the 'preferred_role'
sysfs attribute.
Unable to handle kernel NULL pointer dereference at virtual address 0028
pgd = f69149ad
[0028] *pgd=
Internal error: Oops: 5 [#1] THUMB2
Modules linked in: tcpci tcpm
CPU: 0 PID: 1882 Comm: bash Not tainted 5.1.18-sama5-armv7-r2 #4
Hardware name: Atmel SAMA5
PC is at tcpm_try_role+0x3a/0x4c [tcpm]
LR is at tcpm_try_role+0x15/0x4c [tcpm]
pc : [] lr : [] psr: 60030033
sp : dc1a1e88 ip : c03fb47d fp :
r10: dc216190 r9 : dc1a1f78 r8 : 0001
r7 : df4ae044 r6 : dd032e90 r5 : dd1ce340 r4 : df4ae054
r3 : r2 : r1 : r0 : df4ae044
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none
Control: 50c53c7d Table: 3efec059 DAC: 0051
Process bash (pid: 1882, stack limit = 0x6a6d4aa5)
Stack: (0xdc1a1e88 to 0xdc1a2000)
1e80: dd05d808 dd1ce340 0001 0007 dd1ce340 c03fb4a7
1ea0: 0007 0007 dc216180 c01e1e03
1ec0: c0907008 dee98b40 c01e1d5d c06106c4 0007 c0194e8b
1ee0: 000a 0400 c01a97db dc22bf00 e000 df4b6a00 df745900
1f00: 0001 0001 00dd c01a9c2f 7aeab3be c0907008 dc22bf00
1f20: c0907008 7aeab3be 0007 dee98b40
1f40: 005dc318 dc1a1f78 0007 c01969f7 000a c01a20cb
1f60: dee98b40 c0907008 dee98b40 005dc318 c0196b9b
1f80: dee98b40 7aeab3be 0074 005dc318 b6f3bdb0 0004 c0101224 dc1a
1fa0: 0004 c0101001 0074 005dc318 0001 005dc318 0007
1fc0: 0074 005dc318 b6f3bdb0 0004 0007 0007
1fe0: 0004 be800880 b6ed35b3 b6e5c746 60030030 0001
[] (tcpm_try_role [tcpm]) from []
(preferred_role_store+0x2b/0x5c)
[] (preferred_role_store) from []
(kernfs_fop_write+0xa7/0x150)
[] (kernfs_fop_write) from [] (__vfs_write+0x1f/0x104)
[] (__vfs_write) from [] (vfs_write+0x6b/0x104)
[] (vfs_write) from [] (ksys_write+0x43/0x94)
[] (ksys_write) from [] (ret_fast_syscall+0x1/0x62)
Since commit 96232cbc6c994 ("usb: typec: tcpm: support get typec and pd
config from device properties"), the 'config' pointer in struct tcpc_dev
is optional when registering a Type-C port. Since it is optional, we have
to check if it is NULL before dereferencing it.
Reported-by: Douglas Gilbert
Cc: Douglas Gilbert
Fixes: 96232cbc6c994 ("usb: typec: tcpm: support get typec and pd config from
device properties")
Signed-off-by: Guenter Roeck
---
v2: Added missing Cc:. Sorry for the noise.
Doug:
I didn't add your Tested-by: since I added more code.
It would be great if you can re-test.
drivers/usb/typec/tcpm/tcpm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Tested-by: Douglas Gilbert
This time the Linux system is an Acme Systems Arietta which is a
Atmel at91sam9g25 based board. Test was run with lk 5.1.19 .
Without the patch I got the oops described above ("PC is at
tcpm_try_role+0x40/0x74 [tcpm]") when writing into the 'preferred_role'
sysfs attribute. With this patch it worked okay.
Today I tried this patch on lk 5.2.5 with the same hardware and it
worked, as expected.
Doug Gilbert
Can't test the "out of protocol" PD Attention command oops because I
don't have another OM13588 at the other end (of the USB-C cable) to
send it. I may be able to solve that problem as well. The OM13588
seems like a good attack vector ... and NXP continue to improve
its software (I'm talking about when it runs with a KL27Z which is
an Arduino clone). It can now read the current capability of an
E-marked USB-C (M to M) cable. The only 5 Amp cable I have is
the one that Apple sells (as an _extra_ (cheapskates) to their 87W
USB-C power adapter (for MacBooks)).
Re: [PATCH] HID: usbhid: Use GFP_KERNEL instead of GFP_ATOMIC when applicable
On Thu, Aug 01, 2019 at 12:06:03PM +0200, walter harms wrote: > > > Am 01.08.2019 09:47, schrieb Christophe JAILLET: > > There is no need to use GFP_ATOMIC when calling 'usb_alloc_coherent()' > > here. These calls are done from probe functions and using GFP_KERNEL should > > be safe. > > The memory itself is used within some interrupts, but it is not a > > problem, once it has been allocated. > > > > Signed-off-by: Christophe JAILLET > > --- > > drivers/hid/usbhid/usbkbd.c | 4 ++-- > > drivers/hid/usbhid/usbmouse.c | 2 +- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c > > index d5b7a696a68c..63e8ef8beb45 100644 > > --- a/drivers/hid/usbhid/usbkbd.c > > +++ b/drivers/hid/usbhid/usbkbd.c > > @@ -239,11 +239,11 @@ static int usb_kbd_alloc_mem(struct usb_device *dev, > > struct usb_kbd *kbd) > > return -1; > > if (!(kbd->led = usb_alloc_urb(0, GFP_KERNEL))) > > return -1; > > - if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma))) > > + if (!(kbd->new = usb_alloc_coherent(dev, 8, GFP_KERNEL, &kbd->new_dma))) > > return -1; > > if (!(kbd->cr = kmalloc(sizeof(struct usb_ctrlrequest), GFP_KERNEL))) > > return -1; > > - if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_ATOMIC, > > &kbd->leds_dma))) > > + if (!(kbd->leds = usb_alloc_coherent(dev, 1, GFP_KERNEL, > > &kbd->leds_dma))) > > return -1; > > > > the kernel style is usually: > kbd->new = usb_alloc_coherent(dev, 8, GFP_ATOMIC, &kbd->new_dma); > if (!kbd->new) > return -1; > > > in usbmouse.c this is done, any reason for the change here ? If you want to be extra-correct, don't return -1, return -ENOMEM. thanks, greg k-h
Re: [PATCH v2 2/2] usbip: Implement SG support to vhci
On 8/1/19 12:38 AM, Suwan Kim wrote: On Mon, Jul 29, 2019 at 10:32:31AM -0600, shuah wrote: On 7/29/19 8:52 AM, Suwan Kim wrote: Hi Shuah, On Tue, Jul 23, 2019 at 06:21:53PM -0600, shuah wrote: Hi Suwan, On 7/5/19 10:43 AM, Suwan Kim wrote: There are bugs on vhci with usb 3.0 storage device. Originally, vhci doesn't supported SG, so USB storage driver on vhci breaks SG list into multiple URBs and it causes error that a transfer got terminated too early because the transfer length for one of the URBs was not divisible by the maxpacket size. In this patch, vhci basically support SG and it sends each SG list entry to the stub driver. Then, the stub driver sees the total length of the buffer and allocates SG table and pages according to the total buffer length calling sgl_alloc(). After the stub driver receives completed URB, it again sends each SG list entry to vhci. If HCD of the server doesn't support SG, the stub driver breaks a single SG reqeust into several URBs and submit them to the server's HCD. When all the split URBs are completed, the stub driver reassembles the URBs into a single return command and sends it to vhci. Signed-off-by: Suwan Kim --- drivers/usb/usbip/stub.h | 7 +- drivers/usb/usbip/stub_main.c| 52 +--- drivers/usb/usbip/stub_rx.c | 207 ++- drivers/usb/usbip/stub_tx.c | 108 +++- drivers/usb/usbip/usbip_common.c | 60 +++-- > drivers/usb/usbip/vhci_hcd.c | 10 +- drivers/usb/usbip/vhci_tx.c | 49 ++-- 7 files changed, 372 insertions(+), 121 deletions(-) While you are working on v3 to fix chekpatch and other issues I pointed out, I have more for you. What happens when you have mismatched server and client side? i.e stub does and vhci doesn't and vice versa. Make sure to run checkpatch. Also check spelling errors in comments and your commit log. I am not sure if your eeror paths are correct. Run usbip_test.sh tools/testing/selftests/drivers/usb/usbip I don't know what mismatch you mentioned. Are you saying "match busid table" at the end of usbip_test.sh? How does it relate to SG support of this patch? Could you tell me more about the problem situation? What happens when usbip_host is running a kernel without the sg support and vhci_hcd does? Just make sure this works with the checks for sg support status as a one of your tests for this sg feature. Now I understand. Thanks for the details! As a result of testing, in the situation where vhci supports SG, but stub does not, or vice versa, usbip works normally. Moreover, because there is no protocol modification, there is no problem in communication between server and client even if the one has a kernel without SG support. In the case of vhci supports SG and stub doesn't, because vhci sends only the total length of the buffer to stub as it did before the patch applied, stub only needs to allocate the required length of buffers regardless of whether vhci supports SG or not. If stub needs to send data buffer to vhci because of IN pipe, stub also sends only total length of buffer as metadata and then send real data as vhci does. Then vhci receive data from stub and store it to the corresponding buffer of SG list entry. In the case of stub that supports SG, if SG buffer is requested by vhci, buffer is allocated by sgl_alloc(). However, stub that does not support SG allocates buffer using only kmalloc(). Therefore, if vhci supports SG and stub doesn't, stub has to allocate buffer with kmalloc() as much as the total length of SG buffer which is quite huge when vhci sends SG request, so it has big overhead in buffer allocation. And for the case of stub supports SG and vhci doesn't, since the USB storage driver checks that vhci doesn't support SG and sends the request to stub by splitting the SG list into multiple URBs, stub allocates a buffer with kmalloc() as it did before this patch. Therefore, everything works normally in a mismatch situation. Looking for you add a test case for that. Please include this in the commit log. I will send the v3 soon. Please send it soon. It would be nice to have this done as soon as possible. thanks, -- Shuah
Re: Linux 5.2, usb: typec: Support for Alternate Modes
Hi Matthew, On Thu, Aug 01, 2019 at 01:16:34PM +0100, Matthew Nicholson wrote: > [Resending as plain text email with attachments.] > > Hi, > The kernel version testing I'm testing on is: v5.2.4-arch1 > I have disabled gmd, which seems to struggle with not being able to > configure displays and becomes unresponsive. > I'm running startx and have an xprofile script that is setting the > displays with xrandr. > > *1. dmesg output* > I have attached two copies of dmesg and lsmod ouputs. > Both are for v5.2.4, one set is where ucsi_acpi is blacklisted, > another with no blacklisted modules. > > *2. The exact XPS13 version* > XPS 13 (9370) Developer edition, ships with Ubuntu. > i7-8550U Processor > > *3. BIOS version* > The output from fwupdmgr get-devices is attached. > XPS 13 9370 Thunderbolt Controller: v33.00 > XPS 13 9370 System Firmware: v0.1.10.0 > Synaptics VMM3332 inside Dell WD15/TB16/TB18 wired Dock: v3.10.002 > > At boot the firmware version listed is 1.10.0 > > *Can you unload the UCSI driver to see if it has any effect?* > No changes in being display functionality. I tried to unload and to > blacklist with config file in /etc/modprode.d In that case the problem is not caused by the Type-C drivers. This is more likely a regression in the Thunderbolt drivers, or the graphics drivers. Adding Mika and the graphics guys. Mika is the Thunderbolt maintainer in Linux kernel. He's away now, but he'll be back on Monday. > When ucsi_acpi is not blacked the error message: > > typec_displayport port1-partner.0: failed to enter mode You can ignore that message for now. It is not fatal in this case. It happens because on this platform the embedded controller firmware does not allow the operating system to do anything to the alternate modes besides detecting them, not even enter or exit them (so the firmware handles the alternate modes on its own). The DisplayPort alt mode driver in Linux kernel does not know that, so it tries to enter DisplayPort mode (most likely the firmware has already entered the mode at this point). That attempt fails, and the driver prints the message, but it really is not fatal in any way. I'll see what could be done about that message, but for now you can just ignore it. > is displayed in dmseg and in getty. > > *Are you able to build you own test kernels?* > It is not something that I have done but it is something I should be able to > do. > > A few more details. > The external monitors are detected and listed as available in xrandr. > I can enable one of them at a time, however attempting to enable both > of them will fail. > The returned error message is: > xrandr: Configure crtc 2 failed > > > On Tue, 30 Jul 2019 at 15:27, Heikki Krogerus > wrote: > > > > Hi Matthew, > > > > Copying the respective mailing list. > > > > On Wed, Jul 17, 2019 at 09:22:10AM +0100, Matthew Nicholson wrote: > > > Hi, > > > > > > Thanks for your work on the linux. > > > > > > I am using dell xps13 with a wd15 type-c docking station, on Archlinux. > > > Under kernel version 5.2 (and 5.2.1) I was running into some issue with > > > having the docking station connected to multiple monitors (Only one > > > monitor > > > would work at a time). > > > I tried to get the monitors working under X/xrandr and wayland/gnome. > > > The issue is not present after downgrading back to linux 5.1.7. > > > > > > I am wondering what I should do to report this or help testing. > > > > I'm going to need some details about your platform: > > > > 1. dmesg output > > 2. The exact XPS13 version > > 3. BIOS version > > > > The UCSI driver got support for alternate modes in v5.2, so I'm > > guessing that is causing this problem, but to be sure, can you unload > > the UCSI driver to see if it has any effect? > > > > % modprobe -r ucsi_acpi > > > > Are you able to build you own test kernels? thanks, -- heikki
About usb_new_device() API
Hi All, I am seeing a peculiar behaviour which I think *might* be caused by usb_new_device(). Since usb_new_device() is one of the core APIs, I cannot explain how PM works for USB device at later point in time. In a particular use-case, our composite USB device exposes HID interface with vendor report descriptor. Since the standard HID-class driver's HID-input part is unable to decode this vendor report descriptor, it is unable to bind itself to this interface. After this, we don't see any L2 requests on USB bus analyser. Obvious reason seems to be, since no driver is bound to interface, there cannot be PM call-backs since driver has these call-backs. But I am expecting that the USB device (which is parent of HID interface) should see L2. The reason being, USB-core seems to properly do runtime get/put wherever needed. And HID interface has no driver, so from USB-core point of view, it is a USB device w/o any interface. (please correct if this is incorrect expectation). With that said, I am confused about usb_new_device() in this context. It seems to call usb_disable_autosuspend() ==> pm_runtime_forbid() ==> increment usage_count. However, it never calls usb_enable_autosuspend() itself. Now since USB PM (and L2) works fine at later point in time (i.e.: after all the interfaces are bound to their appropriate drivers), I think somewhere the equivalent of usb_enable_autosuspend() gets called for the USB device and hence USB PM works fine. I wonder this *may be* be an issue I am seeing with the use-case mentioned above. But definitely confused about it and hence thought of sending this email. Does this description makes sense? Is it necessary to call usb_enable_autosuspend() in usb_new_device()? Thanks,
KASAN: use-after-free Read in hiddev_release
Hello, syzbot found the following crash on: HEAD commit:e96407b4 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=147ac20c60 kernel config: https://syzkaller.appspot.com/x/.config?x=792eb47789f57810 dashboard link: https://syzkaller.appspot.com/bug?extid=62a1e04fd3ec2abf099e 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+62a1e04fd3ec2abf0...@syzkaller.appspotmail.com == BUG: KASAN: use-after-free in __lock_acquire+0x302a/0x3b50 kernel/locking/lockdep.c:3753 Read of size 8 at addr 8881cf591a08 by task syz-executor.1/26260 CPU: 1 PID: 26260 Comm: syz-executor.1 Not tainted 5.3.0-rc2+ #24 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 print_address_description+0x6a/0x32c mm/kasan/report.c:351 __kasan_report.cold+0x1a/0x33 mm/kasan/report.c:482 kasan_report+0xe/0x12 mm/kasan/common.c:612 __lock_acquire+0x302a/0x3b50 kernel/locking/lockdep.c:3753 lock_acquire+0x127/0x320 kernel/locking/lockdep.c:4412 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x32/0x50 kernel/locking/spinlock.c:159 hiddev_release+0x82/0x520 drivers/hid/usbhid/hiddev.c:221 __fput+0x2d7/0x840 fs/file_table.c:280 task_work_run+0x13f/0x1c0 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x8ef/0x2c50 kernel/exit.c:878 do_group_exit+0x125/0x340 kernel/exit.c:982 get_signal+0x466/0x23d0 kernel/signal.c:2728 do_signal+0x88/0x14e0 arch/x86/kernel/signal.c:815 exit_to_usermode_loop+0x1a2/0x200 arch/x86/entry/common.c:159 prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline] syscall_return_slowpath arch/x86/entry/common.c:274 [inline] do_syscall_64+0x45f/0x580 arch/x86/entry/common.c:299 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x459829 Code: fd b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f75b2a6ccf8 EFLAGS: 0246 ORIG_RAX: 00ca RAX: fe00 RBX: 0075c078 RCX: 00459829 RDX: RSI: 0080 RDI: 0075c078 RBP: 0075c070 R08: R09: R10: R11: 0246 R12: 0075c07c R13: 7ffcdfe1023f R14: 7f75b2a6d9c0 R15: 0075c07c Allocated by task 104: save_stack+0x1b/0x80 mm/kasan/common.c:69 set_track mm/kasan/common.c:77 [inline] __kasan_kmalloc mm/kasan/common.c:487 [inline] __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:460 kmalloc include/linux/slab.h:552 [inline] kzalloc include/linux/slab.h:748 [inline] hiddev_connect+0x242/0x5b0 drivers/hid/usbhid/hiddev.c:900 hid_connect+0x239/0xbb0 drivers/hid/hid-core.c:1882 hid_hw_start drivers/hid/hid-core.c:1981 [inline] hid_hw_start+0xa2/0x130 drivers/hid/hid-core.c:1972 appleir_probe+0x13e/0x1a0 drivers/hid/hid-appleir.c:308 hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2209 really_probe+0x281/0x650 drivers/base/dd.c:548 driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816 bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 __device_attach+0x217/0x360 drivers/base/dd.c:882 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 device_add+0xae6/0x16f0 drivers/base/core.c:2114 hid_add_device+0x33c/0x990 drivers/hid/hid-core.c:2365 usbhid_probe+0xa81/0xfa0 drivers/hid/usbhid/hid-core.c:1386 usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 really_probe+0x281/0x650 drivers/base/dd.c:548 driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816 bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 __device_attach+0x217/0x360 drivers/base/dd.c:882 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 device_add+0xae6/0x16f0 drivers/base/core.c:2114 usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023 generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210 usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266 really_probe+0x281/0x650 drivers/base/dd.c:548 driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816 bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 __device_attach+0x217/0x360 drivers/base/dd.c:882 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 device_add+0xae6/0x16f0 drivers/base/core.c:2114 usb_new_device.cold+0x6a4/0xe79 driver
possible deadlock in iowarrior_open
Hello,
syzbot found the following crash on:
HEAD commit:7f7867ff 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=17ab6aec60
kernel config: https://syzkaller.appspot.com/x/.config?x=792eb47789f57810
dashboard link: https://syzkaller.appspot.com/bug?extid=ca52394faa436d8131df
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+ca52394faa436d813...@syzkaller.appspotmail.com
==
WARNING: possible circular locking dependency detected
5.3.0-rc2+ #23 Not tainted
--
syz-executor.0/10062 is trying to acquire lock:
527cb8c7 (iowarrior_open_disc_lock){+.+.}, at:
iowarrior_open+0x8a/0x2a0 drivers/usb/misc/iowarrior.c:600
but task is already holding lock:
61445bc7 (iowarrior_mutex){+.+.}, at: iowarrior_open+0x23/0x2a0
drivers/usb/misc/iowarrior.c:589
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (iowarrior_mutex){+.+.}:
__mutex_lock_common kernel/locking/mutex.c:930 [inline]
__mutex_lock+0x158/0x1360 kernel/locking/mutex.c:1077
iowarrior_open+0x23/0x2a0 drivers/usb/misc/iowarrior.c:589
usb_open+0x1df/0x270 drivers/usb/core/file.c:48
chrdev_open+0x219/0x5c0 fs/char_dev.c:414
do_dentry_open+0x494/0x1120 fs/open.c:797
do_last fs/namei.c:3416 [inline]
path_openat+0x1430/0x3f50 fs/namei.c:3533
do_filp_open+0x1a1/0x280 fs/namei.c:3563
do_sys_open+0x3c0/0x580 fs/open.c:1089
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #1 (minor_rwsem#2){}:
down_write+0x92/0x150 kernel/locking/rwsem.c:1500
usb_deregister_dev drivers/usb/core/file.c:238 [inline]
usb_deregister_dev+0x61/0x270 drivers/usb/core/file.c:230
iowarrior_disconnect+0xa8/0x2c0 drivers/usb/misc/iowarrior.c:873
usb_unbind_interface+0x1bd/0x8a0 drivers/usb/core/driver.c:423
__device_release_driver drivers/base/dd.c:1120 [inline]
device_release_driver_internal+0x404/0x4c0 drivers/base/dd.c:1151
bus_remove_device+0x2dc/0x4a0 drivers/base/bus.c:556
device_del+0x420/0xb10 drivers/base/core.c:2288
usb_disable_device+0x211/0x690 drivers/usb/core/message.c:1237
usb_disconnect+0x284/0x8d0 drivers/usb/core/hub.c:2199
hub_port_connect drivers/usb/core/hub.c:4949 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
port_event drivers/usb/core/hub.c:5359 [inline]
hub_event+0x1454/0x3640 drivers/usb/core/hub.c:5441
process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
worker_thread+0x96/0xe20 kernel/workqueue.c:2415
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
-> #0 (iowarrior_open_disc_lock){+.+.}:
check_prev_add kernel/locking/lockdep.c:2405 [inline]
check_prevs_add kernel/locking/lockdep.c:2507 [inline]
validate_chain kernel/locking/lockdep.c:2897 [inline]
__lock_acquire+0x1f7c/0x3b50 kernel/locking/lockdep.c:3880
lock_acquire+0x127/0x320 kernel/locking/lockdep.c:4412
__mutex_lock_common kernel/locking/mutex.c:930 [inline]
__mutex_lock+0x158/0x1360 kernel/locking/mutex.c:1077
iowarrior_open+0x8a/0x2a0 drivers/usb/misc/iowarrior.c:600
usb_open+0x1df/0x270 drivers/usb/core/file.c:48
chrdev_open+0x219/0x5c0 fs/char_dev.c:414
do_dentry_open+0x494/0x1120 fs/open.c:797
do_last fs/namei.c:3416 [inline]
path_openat+0x1430/0x3f50 fs/namei.c:3533
do_filp_open+0x1a1/0x280 fs/namei.c:3563
do_sys_open+0x3c0/0x580 fs/open.c:1089
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Chain exists of:
iowarrior_open_disc_lock --> minor_rwsem#2 --> iowarrior_mutex
Possible unsafe locking scenario:
CPU0CPU1
lock(iowarrior_mutex);
lock(minor_rwsem#2);
lock(iowarrior_mutex);
lock(iowarrior_open_disc_lock);
*** DEADLOCK ***
2 locks held by syz-executor.0/10062:
#0: 0fd8903d (minor_rwsem#2){}, at: usb_open+0x23/0x270
drivers/usb/core/file.c:39
#1: 61445bc7 (iowarrior_mutex){+.+.}, at:
iowarrior_open+0x23/0x2a0 drivers/usb/misc/iowarrior.c:589
stack backtrace:
CPU: 0 PID: 10062 Comm: syz-executor.0 Not tainted 5.3.0-rc2+ #23
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack
possible deadlock in open_rio
Hello,
syzbot found the following crash on:
HEAD commit:7f7867ff 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=136b6aec60
kernel config: https://syzkaller.appspot.com/x/.config?x=792eb47789f57810
dashboard link: https://syzkaller.appspot.com/bug?extid=7bbcbe9c9ff0cd49592a
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+7bbcbe9c9ff0cd495...@syzkaller.appspotmail.com
==
WARNING: possible circular locking dependency detected
5.3.0-rc2+ #23 Not tainted
--
syz-executor.2/20386 is trying to acquire lock:
772249c6 (rio500_mutex){+.+.}, at: open_rio+0x16/0xc0
drivers/usb/misc/rio500.c:64
but task is already holding lock:
d3e8f4b9 (minor_rwsem){}, at: usb_open+0x23/0x270
drivers/usb/core/file.c:39
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (minor_rwsem){}:
down_write+0x92/0x150 kernel/locking/rwsem.c:1500
usb_register_dev drivers/usb/core/file.c:187 [inline]
usb_register_dev+0x131/0x6a0 drivers/usb/core/file.c:156
probe_rio.cold+0x53/0x21d drivers/usb/misc/rio500.c:468
usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023
generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210
usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266
really_probe+0x281/0x650 drivers/base/dd.c:548
driver_probe_device+0x101/0x1b0 drivers/base/dd.c:709
__device_attach_driver+0x1c2/0x220 drivers/base/dd.c:816
bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454
__device_attach+0x217/0x360 drivers/base/dd.c:882
bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514
device_add+0xae6/0x16f0 drivers/base/core.c:2114
usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2536
hub_port_connect drivers/usb/core/hub.c:5098 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5213 [inline]
port_event drivers/usb/core/hub.c:5359 [inline]
hub_event+0x1b5c/0x3640 drivers/usb/core/hub.c:5441
process_one_work+0x92b/0x1530 kernel/workqueue.c:2269
worker_thread+0x96/0xe20 kernel/workqueue.c:2415
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
-> #0 (rio500_mutex){+.+.}:
check_prev_add kernel/locking/lockdep.c:2405 [inline]
check_prevs_add kernel/locking/lockdep.c:2507 [inline]
validate_chain kernel/locking/lockdep.c:2897 [inline]
__lock_acquire+0x1f7c/0x3b50 kernel/locking/lockdep.c:3880
lock_acquire+0x127/0x320 kernel/locking/lockdep.c:4412
__mutex_lock_common kernel/locking/mutex.c:930 [inline]
__mutex_lock+0x158/0x1360 kernel/locking/mutex.c:1077
open_rio+0x16/0xc0 drivers/usb/misc/rio500.c:64
usb_open+0x1df/0x270 drivers/usb/core/file.c:48
chrdev_open+0x219/0x5c0 fs/char_dev.c:414
do_dentry_open+0x494/0x1120 fs/open.c:797
do_last fs/namei.c:3416 [inline]
path_openat+0x1430/0x3f50 fs/namei.c:3533
do_filp_open+0x1a1/0x280 fs/namei.c:3563
do_sys_open+0x3c0/0x580 fs/open.c:1089
do_syscall_64+0xb7/0x580 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0CPU1
lock(minor_rwsem);
lock(rio500_mutex);
lock(minor_rwsem);
lock(rio500_mutex);
*** DEADLOCK ***
1 lock held by syz-executor.2/20386:
#0: d3e8f4b9 (minor_rwsem){}, at: usb_open+0x23/0x270
drivers/usb/core/file.c:39
stack backtrace:
CPU: 1 PID: 20386 Comm: syz-executor.2 Not tainted 5.3.0-rc2+ #23
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
check_noncircular+0x345/0x3e0 kernel/locking/lockdep.c:1741
check_prev_add kernel/locking/lockdep.c:2405 [inline]
check_prevs_add kernel/locking/lockdep.c:2507 [inline]
validate_c
KMSAN: kernel-usb-infoleak in usbnet_write_cmd
Hello, syzbot found the following crash on: HEAD commit:41550654 [UPSTREAM] KVM: x86: degrade WARN to pr_warn_rate.. git tree: kmsan console output: https://syzkaller.appspot.com/x/log.txt?x=13a0b07da0 kernel config: https://syzkaller.appspot.com/x/.config?x=40511ad0c5945201 dashboard link: https://syzkaller.appspot.com/bug?extid=b33fff3d3de984c82064 compiler: clang version 9.0.0 (/home/glider/llvm/clang 80fee25776c2fb61e74c1ecb1a523375c2500b69) 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+b33fff3d3de984c82...@syzkaller.appspotmail.com ax88179_178a 3-1:0.239 (unnamed net_device) (uninitialized): Failed to write reg index 0x001f: -71 ax88179_178a 3-1:0.239 (unnamed net_device) (uninitialized): Failed to write reg index 0x001e: -71 ax88179_178a 3-1:0.239 (unnamed net_device) (uninitialized): Failed to read reg index 0x001a: -71 ax88179_178a 3-1:0.239 (unnamed net_device) (uninitialized): Failed to read reg index 0x001c: -71 == BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x7ef/0x1f50 drivers/usb/core/urb.c:405 CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.2.0-rc4+ #7 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x162/0x2d0 mm/kmsan/kmsan.c:611 kmsan_internal_check_memory+0x974/0xa80 mm/kmsan/kmsan.c:705 kmsan_handle_urb+0x28/0x40 mm/kmsan/kmsan_hooks.c:617 usb_submit_urb+0x7ef/0x1f50 drivers/usb/core/urb.c:405 usb_start_wait_urb+0x143/0x410 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x49f/0x7f0 drivers/usb/core/message.c:156 __usbnet_write_cmd drivers/net/usb/usbnet.c:2020 [inline] usbnet_write_cmd+0x386/0x430 drivers/net/usb/usbnet.c:2058 __ax88179_write_cmd drivers/net/usb/ax88179_178a.c:223 [inline] ax88179_write_cmd drivers/net/usb/ax88179_178a.c:323 [inline] ax88179_led_setting+0x1c76/0x2be0 drivers/net/usb/ax88179_178a.c:1184 ax88179_bind+0xe01/0x1a10 drivers/net/usb/ax88179_178a.c:1305 usbnet_probe+0x10d3/0x3950 drivers/net/usb/usbnet.c:1722 usb_probe_interface+0xd19/0x1310 drivers/usb/core/driver.c:361 really_probe+0x1344/0x1d90 drivers/base/dd.c:513 driver_probe_device+0x1ba/0x510 drivers/base/dd.c:670 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:777 bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454 __device_attach+0x489/0x750 drivers/base/dd.c:843 device_initial_probe+0x4a/0x60 drivers/base/dd.c:890 bus_probe_device+0x131/0x390 drivers/base/bus.c:514 device_add+0x25b5/0x2df0 drivers/base/core.c:2111 usb_set_configuration+0x309f/0x3710 drivers/usb/core/message.c:2027 generic_probe+0xe7/0x280 drivers/usb/core/generic.c:210 usb_probe_device+0x146/0x200 drivers/usb/core/driver.c:266 really_probe+0x1344/0x1d90 drivers/base/dd.c:513 driver_probe_device+0x1ba/0x510 drivers/base/dd.c:670 __device_attach_driver+0x5b8/0x790 drivers/base/dd.c:777 bus_for_each_drv+0x28e/0x3b0 drivers/base/bus.c:454 __device_attach+0x489/0x750 drivers/base/dd.c:843 device_initial_probe+0x4a/0x60 drivers/base/dd.c:890 bus_probe_device+0x131/0x390 drivers/base/bus.c:514 device_add+0x25b5/0x2df0 drivers/base/core.c:2111 usb_new_device+0x23e5/0x2fb0 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+0x5853/0x7320 drivers/usb/core/hub.c:5432 process_one_work+0x1572/0x1f00 kernel/workqueue.c:2269 worker_thread+0x111b/0x2460 kernel/workqueue.c:2415 kthread+0x4b5/0x4f0 kernel/kthread.c:256 ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:355 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:201 [inline] kmsan_save_stack mm/kmsan/kmsan.c:213 [inline] kmsan_internal_chain_origin+0xcc/0x150 mm/kmsan/kmsan.c:414 kmsan_memcpy_memmove_metadata+0x9f9/0xe00 mm/kmsan/kmsan.c:297 kmsan_memcpy_metadata+0xb/0x10 mm/kmsan/kmsan.c:317 __msan_memcpy+0x56/0x70 mm/kmsan/kmsan_instr.c:139 kmemdup+0x107/0x140 mm/util.c:121 __usbnet_write_cmd drivers/net/usb/usbnet.c:2009 [inline] usbnet_write_cmd+0x168/0x430 drivers/net/usb/usbnet.c:2058 __ax88179_write_cmd drivers/net/usb/ax88179_178a.c:223 [inline] ax88179_write_cmd drivers/net/usb/ax88179_178a.c:323 [inline] ax88179_led_setting+0x1c76/0x2be0 drivers/net/usb/ax88179_178a.c:1184 ax88179_bind+0xe01/0x1a10 drivers/net/usb/ax88179_178a.c:1305 usbnet_probe+0x10d3/0x3950 drivers/net/usb/usbnet.c:1722 usb_probe_interface+0xd19/0x1310 drivers/usb/core/driver.c:361 really_probe+0x1344/0x1d90 drivers/base/dd.c:513 driver_probe_device+0x1ba/0x510 drivers/base/dd.c:670 __device_attach_driver+
WARNING in sysfs_create_file_ns
Hello, syzbot found the following crash on: HEAD commit:7829a896 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=1211944060 kernel config: https://syzkaller.appspot.com/x/.config?x=f6d4561982f71f63 dashboard link: https://syzkaller.appspot.com/bug?extid=5b9bba68c833c84a1135 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1486787fa0 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11aa97d860 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+5b9bba68c833c84a1...@syzkaller.appspotmail.com usbvision_audio_off: can't write reg usb 1-1: usbvision_write_reg: failed: error -2 usb 1-1: usbvision_write_reg: failed: error -2 usb 1-1: usbvision_write_reg: failed: error -2 usb 1-1: usbvision_write_reg: failed: error -2 usb 1-1: usbvision_write_reg: failed: error -2 usbvision_i2c_register: can't write reg videodev: could not get a free minor usb 1-1: USBVision[129]: video_register_device() failed WARNING: CPU: 1 PID: 22 at fs/sysfs/file.c:327 sysfs_create_file_ns+0x13c/0x1c0 fs/sysfs/file.c:327 Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 22 Comm: kworker/1:1 Not tainted 5.2.0-rc6+ #13 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 panic+0x292/0x6c9 kernel/panic.c:219 __warn.cold+0x20/0x4b kernel/panic.c:576 report_bug+0x262/0x2a0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:179 [inline] fixup_bug arch/x86/kernel/traps.c:174 [inline] do_error_trap+0x12b/0x1e0 arch/x86/kernel/traps.c:272 do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:291 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:986 RIP: 0010:sysfs_create_file_ns+0x13c/0x1c0 fs/sysfs/file.c:327 Code: 85 82 00 00 00 41 55 48 8b 7b 30 31 d2 48 89 ee 44 8b 4c 24 50 44 8b 44 24 40 e8 af f9 ff ff 41 89 c5 58 eb 0d e8 54 85 b6 ff <0f> 0b 41 bd ea ff ff ff e8 47 85 b6 ff 44 89 e8 48 ba 00 00 00 00 RSP: 0018:8881d9f97130 EFLAGS: 00010293 RAX: 8881d9f88000 RBX: 8881cbb0a490 RCX: 8266f244 RDX: RSI: 8186565c RDI: 8881cbb0a490 RBP: 8779e1a0 R08: 8881d9f88000 R09: ed103b665d30 R10: ed103b665d2f R11: 8881db32e97f R12: 11103b3f2e27 R13: R14: dc00 R15: 8881cbb0a4c0 sysfs_create_file include/linux/sysfs.h:513 [inline] device_create_file+0xe6/0x1d0 drivers/base/core.c:1559 usbvision_create_sysfs drivers/media/usb/usbvision/usbvision-video.c:252 [inline] usbvision_probe.cold+0x1a73/0x1d69 drivers/media/usb/usbvision/usbvision-video.c:1530 usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 really_probe+0x281/0x660 drivers/base/dd.c:509 driver_probe_device+0x104/0x210 drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 __device_attach+0x217/0x360 drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 device_add+0xae6/0x16f0 drivers/base/core.c:2111 usb_set_configuration+0xdf6/0x1670 drivers/usb/core/message.c:2023 generic_probe+0x9d/0xd5 drivers/usb/core/generic.c:210 usb_probe_device+0x99/0x100 drivers/usb/core/driver.c:266 really_probe+0x281/0x660 drivers/base/dd.c:509 driver_probe_device+0x104/0x210 drivers/base/dd.c:670 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:777 bus_for_each_drv+0x15c/0x1e0 drivers/base/bus.c:454 __device_attach+0x217/0x360 drivers/base/dd.c:843 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:514 device_add+0xae6/0x16f0 drivers/base/core.c:2111 usb_new_device.cold+0x8c1/0x1016 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+0x1ada/0x3590 drivers/usb/core/hub.c:5432 process_one_work+0x905/0x1570 kernel/workqueue.c:2269 worker_thread+0x96/0xe20 kernel/workqueue.c:2415 kthread+0x30b/0x410 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Kernel Offset: disabled Rebooting in 86400 seconds.. --- 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 syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: KASAN: use-after-free Read in device_release_driver_internal
On Tue, Jul 23, 2019 at 4:28 PM syzbot wrote: > > Hello, > > syzbot found the following crash on: > > HEAD commit:6a3599ce 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=13f640cc60 > kernel config: https://syzkaller.appspot.com/x/.config?x=700ca426ab83faae > dashboard link: https://syzkaller.appspot.com/bug?extid=1b2449b7b5dc240d107a > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116ce31fa0 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1022f69460 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+1b2449b7b5dc240d1...@syzkaller.appspotmail.com > > usb 1-1: USB disconnect, device number 2 > == > BUG: KASAN: use-after-free in __lock_acquire+0x3a5d/0x5340 > /kernel/locking/lockdep.c:3665 > Read of size 8 at addr 8881cfc4ef90 by task kworker/0:2/108 > > CPU: 0 PID: 108 Comm: kworker/0:2 Not tainted 5.2.0-rc6+ #15 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > Google 01/01/2011 > Workqueue: usb_hub_wq hub_event > Call Trace: > __dump_stack /lib/dump_stack.c:77 [inline] > dump_stack+0xca/0x13e /lib/dump_stack.c:113 > print_address_description+0x67/0x231 /mm/kasan/report.c:188 > __kasan_report.cold+0x1a/0x32 /mm/kasan/report.c:317 > kasan_report+0xe/0x20 /mm/kasan/common.c:614 > __lock_acquire+0x3a5d/0x5340 /kernel/locking/lockdep.c:3665 > lock_acquire+0x100/0x2b0 /kernel/locking/lockdep.c:4303 > __mutex_lock_common /kernel/locking/mutex.c:926 [inline] > __mutex_lock+0xf9/0x12b0 /kernel/locking/mutex.c:1073 > device_release_driver_internal+0x23/0x4c0 /drivers/base/dd.c:1109 > bus_remove_device+0x2dc/0x4a0 /drivers/base/bus.c:556 > device_del+0x460/0xb80 /drivers/base/core.c:2274 > usb_disable_device+0x211/0x690 /drivers/usb/core/message.c:1237 > usb_disconnect+0x284/0x830 /drivers/usb/core/hub.c:2199 > hub_port_connect /drivers/usb/core/hub.c:4949 [inline] > hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] > port_event /drivers/usb/core/hub.c:5359 [inline] > hub_event+0x13bd/0x3550 /drivers/usb/core/hub.c:5441 > process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 > worker_thread+0x96/0xe20 /kernel/workqueue.c:2415 > kthread+0x30b/0x410 /kernel/kthread.c:255 > ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 > > Allocated by task 88: > save_stack+0x1b/0x80 /mm/kasan/common.c:71 > set_track /mm/kasan/common.c:79 [inline] > __kasan_kmalloc /mm/kasan/common.c:489 [inline] > __kasan_kmalloc.constprop.0+0xbf/0xd0 /mm/kasan/common.c:462 > kmalloc /./include/linux/slab.h:547 [inline] > kzalloc /./include/linux/slab.h:742 [inline] > usb_set_configuration+0x2c4/0x1670 /drivers/usb/core/message.c:1846 > generic_probe+0x9d/0xd5 /drivers/usb/core/generic.c:210 > usb_probe_device+0x99/0x100 /drivers/usb/core/driver.c:266 > really_probe+0x281/0x660 /drivers/base/dd.c:509 > driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 > __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 > bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 > __device_attach+0x217/0x360 /drivers/base/dd.c:843 > bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 > device_add+0xae6/0x16f0 /drivers/base/core.c:2111 > usb_new_device.cold+0x6a4/0xe61 /drivers/usb/core/hub.c:2536 > hub_port_connect /drivers/usb/core/hub.c:5098 [inline] > hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] > port_event /drivers/usb/core/hub.c:5359 [inline] > hub_event+0x1abd/0x3550 /drivers/usb/core/hub.c:5441 > process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 > worker_thread+0x96/0xe20 /kernel/workqueue.c:2415 > kthread+0x30b/0x410 /kernel/kthread.c:255 > ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 > > Freed by task 108: > save_stack+0x1b/0x80 /mm/kasan/common.c:71 > set_track /mm/kasan/common.c:79 [inline] > __kasan_slab_free+0x130/0x180 /mm/kasan/common.c:451 > slab_free_hook /mm/slub.c:1421 [inline] > slab_free_freelist_hook /mm/slub.c:1448 [inline] > slab_free /mm/slub.c:2994 [inline] > kfree+0xd7/0x280 /mm/slub.c:3949 > device_release+0x71/0x200 /drivers/base/core.c:1064 > kobject_cleanup /lib/kobject.c:691 [inline] > kobject_release /lib/kobject.c:720 [inline] > kref_put /./include/linux/kref.h:65 [inline] > kobject_put+0x171/0x280 /lib/kobject.c:737 > put_device+0x1b/0x30 /drivers/base/core.c:2210 > klist_put+0xce/0x170 /lib/klist.c:221 > bus_remove_device+0x3a4/0x4a0 /drivers/base/bus.c:552 > device_del+0x460/0xb80 /drivers/base/core.c:2274 > usb_disable_device+0x211/0x690 /drivers/usb/core/message.c:1237 > usb_disconnect+0x284/0x830 /drivers/usb/core/hub.c:2199 > hub_port_connect /drivers/usb/core/hub.c:4949 [inline
Re: [RFC PATCH] usb: typec: tcpm: Ignore unsupported/unknown alternate mode requests
On Wed, Jul 31, 2019 at 12:55:55PM +0300, Heikki Krogerus wrote:
> On Tue, Jul 30, 2019 at 06:28:52AM -0700, Guenter Roeck wrote:
> > On 7/30/19 5:07 AM, Heikki Krogerus wrote:
> > > On Mon, Jul 29, 2019 at 10:31:04AM -0700, Guenter Roeck wrote:
> > > > On Mon, Jul 29, 2019 at 05:04:57PM +0300, Heikki Krogerus wrote:
> > > > > Hi,
> > > > >
> > > > > On Wed, Jul 24, 2019 at 09:30:37PM -0700, Guenter Roeck wrote:
> > > > > > TCPM may receive PD messages associated with unknown or unsupported
> > > > > > alternate modes. If that happens, calls to typec_match_altmode()
> > > > > > will return NULL. The tcpm code does not currently take this into
> > > > > > account. This results in crashes.
> > > > > >
> > > > > > Unable to handle kernel NULL pointer dereference at virtual address
> > > > > > 01f0
> > > > > > pgd = 41dad9a1
> > > > > > [01f0] *pgd=
> > > > > > Internal error: Oops: 5 [#1] THUMB2
> > > > > > Modules linked in: tcpci tcpm
> > > > > > CPU: 0 PID: 2338 Comm: kworker/u2:0 Not tainted
> > > > > > 5.1.18-sama5-armv7-r2 #6
> > > > > > Hardware name: Atmel SAMA5
> > > > > > Workqueue: 2-0050 tcpm_pd_rx_handler [tcpm]
> > > > > > PC is at typec_altmode_attention+0x0/0x14
> > > > > > LR is at tcpm_pd_rx_handler+0xa3b/0xda0 [tcpm]
> > > > > > ...
> > > > > > [] (typec_altmode_attention) from []
> > > > > > (tcpm_pd_rx_handler+0xa3b/0xda0 [tcpm])
> > > > > > [] (tcpm_pd_rx_handler [tcpm]) from []
> > > > > > (process_one_work+0x123/0x2a8)
> > > > > > [] (process_one_work) from []
> > > > > > (worker_thread+0xbd/0x3b0)
> > > > > > [] (worker_thread) from [] (kthread+0xcf/0xf4)
> > > > > > [] (kthread) from [] (ret_from_fork+0x11/0x38)
> > > > > >
> > > > > > Ignore PD messages if the asociated alternate mode is not supported.
> > > > > >
> > > > > > Reported-by: Douglas Gilbert
> > > > > > Cc: Douglas Gilbert
> > > > > > Fixes: e9576fe8e605c ("usb: typec: tcpm: Support for Alternate
> > > > > > Modes")
> > > > > > Signed-off-by: Guenter Roeck
> > > > > > ---
> > > > > > Taking a stab at the problem. I don't really know if this is the
> > > > > > correct
> > > > > > fix, or even if my understanding of the problem is correct, thus
> > > > > > marking
> > > > > > the patch as RFC.
> > > > >
> > > > > My guess is that typec_match_altmode() is the real culprit. We can't
> > > > > rely on the partner mode index number when identifying the port alt
> > > > > mode.
> > > > >
> > > > > Douglas, can you test the attached hack instead of this patch?
> > > > >
> > > > >
> > > > > thanks,
> > > > >
> > > > > --
> > > > > heikki
> > > >
> > > > > diff --git a/drivers/usb/typec/tcpm/tcpm.c
> > > > > b/drivers/usb/typec/tcpm/tcpm.c
> > > > > index ec525811a9eb..033dc097ba83 100644
> > > > > --- a/drivers/usb/typec/tcpm/tcpm.c
> > > > > +++ b/drivers/usb/typec/tcpm/tcpm.c
> > > > > @@ -1067,12 +1067,11 @@ static int tcpm_pd_svdm(struct tcpm_port
> > > > > *port, const __le32 *payload, int cnt,
> > > > > modep = &port->mode_data;
> > > > > - adev = typec_match_altmode(port->port_altmode,
> > > > > ALTMODE_DISCOVERY_MAX,
> > > > > -PD_VDO_VID(p[0]), PD_VDO_OPOS(p[0]));
> > > > > -
> > > > > pdev = typec_match_altmode(port->partner_altmode,
> > > > > ALTMODE_DISCOVERY_MAX,
> > > > > PD_VDO_VID(p[0]), PD_VDO_OPOS(p[0]));
> > > > > + adev = (void *)typec_altmode_get_partner(pdev);
> > > > > +
> > > >
> > > > I understand that typec_altmode_get_partner() returns a const *;
> > > > maybe adev should be declared as const struct typec_altmode *
> > > > instead of using a typecast.
> > >
> > > Yes...
> > >
> > > > Also, typec_altmode_get_partner() can return NULL as well if pdev is
> > > > NULL.
> > > > Is it guaranteed that typec_match_altmode() never returns NULL for pdev
> > > > ?
> > >
> > > ...and probable no. But I don't think we can receive Attention to a
> > > mode that hasn't been entered.
> > >
> >
> > If I understand correctly, the Attention was generated by a test system.
> > What prevents badly implemented code in the connected system from sending
> > such an Attention message ?
>
> Oh, if that is the case, then I don't think my change has any effect.
> I misunderstood the scenario. Sorry for that.
>
> I think we should use your patch to fix this issue.
So is this an "ack"? I'm confused as to if this patch should be applied
or not...
thanks,
greg k-h
Re: Unhandled fault: imprecise external abort (0x1406) when loading xhci_pci.ko - uPD720202, PEX8605, iMX6Q and linux-4.19.25
[+cc i.MX6 folks] On Thu, Aug 01, 2019 at 10:18:22AM +0200, Fawad Lateef wrote: > Hi everyone, > > I am trying to get Renesas uPD720202 USB3.0 hub working which is > connected PCIe switch (PEX8605); PEX8605 is connected to i.MX6Q > through its x1 PCIe Gen2 interface. Running Linux-4.19.25 vanilla > kernel with patches from Phytec.de for their Phycore-iMX6Q SOM. > > We have 2x PEX8605 ports connected to mPCIe slots and 2x WLAN modules > (QCA9880) working perfectly. > > Facing kernel "Unhandled fault: imprecise external abort (0x1406)" > when trying to load xhci_pci.ko module for uPD720202. Receiving this > fault straight-away when driver trying to setup device. > > uPD720202 don't have external EEPROM support, so I have to load > firmware in chips memory before loading the driver. Sometimes after > loading the driver, I see the USB3.0 hub but then doing "lsusb -v" > crashes the driver with same above mentioned fault. I'm guessing this is an MMIO read to the xHCI that failed. When an MIMO read fails, most systems just return 0x data without causing an exception. Can you tell if the external abort is related to a CPU memory access? If so, can you find the address? If it's an MMIO access to the xHCI, it should be in the [mem 0x0110-0x01101fff 64bit] range assigned to its BAR 0, but I didn't see any likely looking addresses in the dump. > Tried to disable DMA from kernel configuration but still same result. > From hardware side verified the RESET pins for PEX8605 and uPD720202 > chips but no change. > > Also wanted to read PCIe switch registers using I2C interface but have > to figure-out how to do that (saw some patches email from Rajat Jain > from 2014 but seems like can't find the patch attachment anywhere on > Google). > > The kernel log is below. Any help or pointers in solving this problem > will be much appreciated. > > [0.00] Booting Linux on physical CPU 0x0 > [0.00] Linux version 4.19.25-bsp-yocto-i.mx6-pd18.1.1 > (br-user@flateef-XPS-13-9360) (gcc version 8.2.0 (Buildroot > 2018.11.4-gebef590b)) #3 SMP Wed Jul 31 11:13:06 UTC 2019 > [0.00] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), > cr=10c5387d > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > instruction cache > [0.00] OF: fdt: Machine model: PHYTEC phyBOARD-Mira Quad full > featured with eMMC > [0.00] Memory policy: Data cache writealloc > [0.00] cma: Reserved 128 MiB at 0x8600 > [0.00] On node 0 totalpages: 524288 > [0.00] Normal zone: 1536 pages used for memmap > [0.00] Normal zone: 0 pages reserved > [0.00] Normal zone: 196608 pages, LIFO batch:63 > [0.00] HighMem zone: 327680 pages, LIFO batch:63 > [0.00] random: get_random_bytes called from > start_kernel+0x88/0x3f8 with crng_init=0 > [0.00] percpu: Embedded 16 pages/cpu @(ptrval) s34828 r8192 > d22516 u65536 > [0.00] pcpu-alloc: s34828 r8192 d22516 u65536 alloc=16*4096 > [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 > [0.00] Built 1 zonelists, mobility grouping on. Total pages: 522752 > [0.00] Kernel command line: console=ttymxc1,115200n8 > root=/dev/mmcblk3p2 rootwait rw > [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 > bytes) > [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > [0.00] Memory: 1934476K/2097152K available (8192K kernel code, > 357K rwdata, 2464K rodata, 1024K init, 398K bss, 31604K reserved, > 131072K cma-reserved, 1178732K highmem) > [0.00] Virtual kernel memory layout: > [0.00] vector : 0x - 0x1000 ( 4 kB) > [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) > [0.00] vmalloc : 0xf080 - 0xff80 ( 240 MB) > [0.00] lowmem : 0xc000 - 0xf000 ( 768 MB) > [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) > [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) > [0.00] .text : 0x(ptrval) - 0x(ptrval) (9184 kB) > [0.00] .init : 0x(ptrval) - 0x(ptrval) (1024 kB) > [0.00] .data : 0x(ptrval) - 0x(ptrval) ( 358 kB) > [0.00].bss : 0x(ptrval) - 0x(ptrval) ( 399 kB) > [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 > [0.00] rcu: Hierarchical RCU implementation. > [0.00] rcu: RCU event tracing is enabled. > [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 > [0.00] L2C-310 errata 752271 769419 enabled > [0.00] L2C-310 enabling early BRESP for Cortex-A9 > [0.00] L2C-310 full line of zeros enabled for Cortex-A9 > [0.00] L2C-310 ID prefetch enabled, offset 16 lines > [0.00] L2C-310 dynamic clock gating enabled, standby mode enabled > [0.00] L2C-310 cache controller enabled, 16 ways, 1024 kB > [0.00] L2C-310: CACHE_ID 0x41c7,
Re: About usb_new_device() API
On Thu, 1 Aug 2019, Mayuresh Kulkarni wrote: > Hi All, > > I am seeing a peculiar behaviour which I think *might* be > caused by usb_new_device(). Since usb_new_device() is one of the core > APIs, I cannot explain how PM works for USB device at later point in > time. > > In a particular use-case, our composite USB device > exposes HID interface with vendor report descriptor. Since the standard > HID-class driver's HID-input part is unable to decode this vendor report > descriptor, it is unable to bind itself to this interface. > After this, we don't see any L2 requests on USB bus analyser. > Obvious reason seems to be, since no driver is bound to interface, there > cannot be PM call-backs since driver has these call-backs. There are other possible reasons. For example, what is the setting stored in /sys/bus/usb/devices/.../power/control (fill in the "..." with the appropriate name for your device)? If the file contains "on" then runtime PM is forbidden and the device will always remain at full power. If the file contains "auto" then the device will be subject to normal runtime-PM suspends and resumes. > But I am expecting that the USB device (which is parent of HID > interface) should see L2. The reason being, USB-core seems to properly > do runtime get/put wherever needed. And HID interface has no driver, so > from USB-core point of view, it is a USB device w/o any interface. > (please correct if this is incorrect expectation). More accurately, it is a USB device with one interface which is not bound to a driver. > With that said, I am confused about usb_new_device() in this context. It > seems to call usb_disable_autosuspend() ==> pm_runtime_forbid() ==> > increment usage_count. Correct. By default, all USB devices except hubs are forbidden to go into runtime suspend. This setting can be changed by userspace (by writing to the sysfs file mentioned above). > However, it never calls usb_enable_autosuspend() itself. > Now since USB PM (and L2) works fine at later point in time (i.e.: after > all the interfaces are bound to their appropriate drivers), I think > somewhere the equivalent of usb_enable_autosuspend() gets called for the > USB device and hence USB PM works fine. There are programs, like powertop, which will automatically write "auto" to the power/control sysfs file when a new device appears. Doing so calls pm_runtime_allow(), which decrements usage_count. > I wonder this *may be* be an issue I am seeing with the use-case > mentioned above. But definitely confused about it and hence thought of > sending this email. > > Does this description makes sense? Is it necessary to > call usb_enable_autosuspend() in usb_new_device()? It is not necessary. Check that sysfs file and see what it contains. In fact, you can check the contents of all the files in the device's sysfs power/ subdirectory. Alan Stern
Re: KASAN: use-after-free Read in device_release_driver_internal
On Thu, 1 Aug 2019, Andrey Konovalov wrote: > On Tue, Jul 23, 2019 at 4:28 PM syzbot > wrote: > > > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit:6a3599ce 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=13f640cc60 > > kernel config: https://syzkaller.appspot.com/x/.config?x=700ca426ab83faae > > dashboard link: https://syzkaller.appspot.com/bug?extid=1b2449b7b5dc240d107a > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=116ce31fa0 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1022f69460 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+1b2449b7b5dc240d1...@syzkaller.appspotmail.com > > > > usb 1-1: USB disconnect, device number 2 > > == > > BUG: KASAN: use-after-free in __lock_acquire+0x3a5d/0x5340 > > /kernel/locking/lockdep.c:3665 > > Read of size 8 at addr 8881cfc4ef90 by task kworker/0:2/108 > > > > CPU: 0 PID: 108 Comm: kworker/0:2 Not tainted 5.2.0-rc6+ #15 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS > > Google 01/01/2011 > > Workqueue: usb_hub_wq hub_event > > Call Trace: > > __dump_stack /lib/dump_stack.c:77 [inline] > > dump_stack+0xca/0x13e /lib/dump_stack.c:113 > > print_address_description+0x67/0x231 /mm/kasan/report.c:188 > > __kasan_report.cold+0x1a/0x32 /mm/kasan/report.c:317 > > kasan_report+0xe/0x20 /mm/kasan/common.c:614 > > __lock_acquire+0x3a5d/0x5340 /kernel/locking/lockdep.c:3665 > > lock_acquire+0x100/0x2b0 /kernel/locking/lockdep.c:4303 > > __mutex_lock_common /kernel/locking/mutex.c:926 [inline] > > __mutex_lock+0xf9/0x12b0 /kernel/locking/mutex.c:1073 > > device_release_driver_internal+0x23/0x4c0 /drivers/base/dd.c:1109 > > bus_remove_device+0x2dc/0x4a0 /drivers/base/bus.c:556 > > device_del+0x460/0xb80 /drivers/base/core.c:2274 > > usb_disable_device+0x211/0x690 /drivers/usb/core/message.c:1237 > > usb_disconnect+0x284/0x830 /drivers/usb/core/hub.c:2199 > > hub_port_connect /drivers/usb/core/hub.c:4949 [inline] > > hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] > > port_event /drivers/usb/core/hub.c:5359 [inline] > > hub_event+0x13bd/0x3550 /drivers/usb/core/hub.c:5441 > > process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 > > worker_thread+0x96/0xe20 /kernel/workqueue.c:2415 > > kthread+0x30b/0x410 /kernel/kthread.c:255 > > ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 > > > > Allocated by task 88: > > save_stack+0x1b/0x80 /mm/kasan/common.c:71 > > set_track /mm/kasan/common.c:79 [inline] > > __kasan_kmalloc /mm/kasan/common.c:489 [inline] > > __kasan_kmalloc.constprop.0+0xbf/0xd0 /mm/kasan/common.c:462 > > kmalloc /./include/linux/slab.h:547 [inline] > > kzalloc /./include/linux/slab.h:742 [inline] > > usb_set_configuration+0x2c4/0x1670 /drivers/usb/core/message.c:1846 > > generic_probe+0x9d/0xd5 /drivers/usb/core/generic.c:210 > > usb_probe_device+0x99/0x100 /drivers/usb/core/driver.c:266 > > really_probe+0x281/0x660 /drivers/base/dd.c:509 > > driver_probe_device+0x104/0x210 /drivers/base/dd.c:670 > > __device_attach_driver+0x1c2/0x220 /drivers/base/dd.c:777 > > bus_for_each_drv+0x15c/0x1e0 /drivers/base/bus.c:454 > > __device_attach+0x217/0x360 /drivers/base/dd.c:843 > > bus_probe_device+0x1e4/0x290 /drivers/base/bus.c:514 > > device_add+0xae6/0x16f0 /drivers/base/core.c:2111 > > usb_new_device.cold+0x6a4/0xe61 /drivers/usb/core/hub.c:2536 > > hub_port_connect /drivers/usb/core/hub.c:5098 [inline] > > hub_port_connect_change /drivers/usb/core/hub.c:5213 [inline] > > port_event /drivers/usb/core/hub.c:5359 [inline] > > hub_event+0x1abd/0x3550 /drivers/usb/core/hub.c:5441 > > process_one_work+0x905/0x1570 /kernel/workqueue.c:2269 > > worker_thread+0x96/0xe20 /kernel/workqueue.c:2415 > > kthread+0x30b/0x410 /kernel/kthread.c:255 > > ret_from_fork+0x24/0x30 /arch/x86/entry/entry_64.S:352 > > > > Freed by task 108: > > save_stack+0x1b/0x80 /mm/kasan/common.c:71 > > set_track /mm/kasan/common.c:79 [inline] > > __kasan_slab_free+0x130/0x180 /mm/kasan/common.c:451 > > slab_free_hook /mm/slub.c:1421 [inline] > > slab_free_freelist_hook /mm/slub.c:1448 [inline] > > slab_free /mm/slub.c:2994 [inline] > > kfree+0xd7/0x280 /mm/slub.c:3949 > > device_release+0x71/0x200 /drivers/base/core.c:1064 > > kobject_cleanup /lib/kobject.c:691 [inline] > > kobject_release /lib/kobject.c:720 [inline] > > kref_put /./include/linux/kref.h:65 [inline] > > kobject_put+0x171/0x280 /lib/kobject.c:737 > > put_device+0x1b/0x30 /drivers/base/core.c:2210 > > klist_put+0xce/0x170 /lib/klist.c:221 > > bus_remove_device+0x3a4/0x4a0 /drivers/base/bus.c:552 >
[PATCH] usb: devio: fix mmap() on non-coherent DMA architectures
From: Gavin Li
On architectures that are not (or are optionally) DMA coherent,
dma_alloc_coherent() returns an address into the vmalloc space,
and calling virt_to_phys() on this address returns an unusable
physical address.
This patch replaces the raw remap_pfn_range() call with a call to
dmap_mmap_coherent(), which takes care of the differences between
coherent and non-coherent code paths.
Tested on an arm64 rk3399 board.
Signed-off-by: Gavin Li
---
drivers/usb/core/devio.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index a02448105527..76ec9aef3eff 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -241,11 +241,10 @@ static int usbdev_mmap(struct file *file, struct
vm_area_struct *vma)
usbm->vma_use_count = 1;
INIT_LIST_HEAD(&usbm->memlist);
- if (remap_pfn_range(vma, vma->vm_start,
- virt_to_phys(usbm->mem) >> PAGE_SHIFT,
- size, vma->vm_page_prot) < 0) {
+ ret = dma_mmap_coherent(ps->dev->bus->sysdev, vma, mem, dma_handle,
size);
+ if (ret) {
dec_usb_memory_use_count(usbm, &usbm->vma_use_count);
- return -EAGAIN;
+ return ret;
}
vma->vm_flags |= VM_IO;
--
2.22.0
[PATCH] usb: devio: fix mmap() on non-coherent DMA architectures
From: Gavin Li
On architectures that are not (or are optionally) DMA coherent,
dma_alloc_coherent() returns an address into the vmalloc space,
and calling virt_to_phys() on this address returns an unusable
physical address.
This patch replaces the raw remap_pfn_range() call with a call to
dmap_mmap_coherent(), which takes care of the differences between
coherent and non-coherent code paths.
Tested on an arm64 rk3399 board.
Signed-off-by: Gavin Li
---
drivers/usb/core/devio.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index a02448105527..76ec9aef3eff 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -241,11 +241,10 @@ static int usbdev_mmap(struct file *file, struct
vm_area_struct *vma)
usbm->vma_use_count = 1;
INIT_LIST_HEAD(&usbm->memlist);
- if (remap_pfn_range(vma, vma->vm_start,
- virt_to_phys(usbm->mem) >> PAGE_SHIFT,
- size, vma->vm_page_prot) < 0) {
+ ret = dma_mmap_coherent(ps->dev->bus->sysdev, vma, mem, dma_handle,
size);
+ if (ret) {
dec_usb_memory_use_count(usbm, &usbm->vma_use_count);
- return -EAGAIN;
+ return ret;
}
vma->vm_flags |= VM_IO;
--
2.22.0
