,On Tue, May 5, 2020 at 3:23 PM Oliver Neukum <oneukum@xxxxxxxx> wrote: > > Am Montag, den 10.02.2020, 17:16 -0800 schrieb syzbot: > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit: e5cd56e9 usb: gadget: add raw-gadget interface > > git tree: https://github.com/google/kasan.git usb-fuzzer > > console output: https://syzkaller.appspot.com/x/log.txt?x=1517fed9e00000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=8cff427cc8996115 > > dashboard link: https://syzkaller.appspot.com/bug?extid=07efed3bc5a1407bd742 > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=147026b5e00000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1683b6b5e00000 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+07efed3bc5a1407bd742@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > betop 0003:20BC:5500.0001: unknown main item tag 0x0 > > betop 0003:20BC:5500.0001: hidraw0: USB HID v0.00 Device [HID 20bc:5500] on usb-dummy_hcd.0-1/input0 > > ================================================================== > > BUG: KASAN: slab-out-of-bounds in set_bit include/asm-generic/bitops/instrumented-atomic.h:28 [inline] > > BUG: KASAN: slab-out-of-bounds in betopff_init drivers/hid/hid-betopff.c:99 [inline] > > BUG: KASAN: slab-out-of-bounds in betop_probe+0x396/0x570 drivers/hid/hid-betopff.c:134 > > Write of size 8 at addr ffff8881d4f43ac0 by task kworker/1:2/94 > > > > Freed by task 12: > > save_stack+0x1b/0x80 mm/kasan/common.c:72 > > set_track mm/kasan/common.c:80 [inline] > > kasan_set_free_info mm/kasan/common.c:337 [inline] > > __kasan_slab_free+0x117/0x160 mm/kasan/common.c:476 > > slab_free_hook mm/slub.c:1444 [inline] > > slab_free_freelist_hook mm/slub.c:1477 [inline] > > slab_free mm/slub.c:3024 [inline] > > kfree+0xd5/0x300 mm/slub.c:3976 > > urb_destroy drivers/usb/core/urb.c:26 [inline] > > kref_put include/linux/kref.h:65 [inline] > > > > Hi, > > this indicates that I am confused. Why are we getting an out-of-bounds > on a freed region? Is this a strange way of reporting access > to already freed memory? Hi Oliver, This is being tracked in: https://bugzilla.kernel.org/show_bug.cgi?id=198425
