* INFO: rcu detected stall in hub_event @ 2019-11-21 14:45 syzbot 2019-11-22 16:51 ` Alan Stern 2022-07-30 10:27 ` [syzbot] " syzbot 0 siblings, 2 replies; 18+ messages in thread From: syzbot @ 2019-11-21 14:45 UTC (permalink / raw) To: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel, linux-usb, syzkaller-bugs Hello, syzbot found the following crash on: HEAD commit: 46178223 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=15a05836e00000 kernel config: https://syzkaller.appspot.com/x/.config?x=99c88c44660624e7 dashboard link: https://syzkaller.appspot.com/bug?extid=ec5f884c4a135aa0dbb9 compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1061395ae00000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13653d1ce00000 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+ec5f884c4a135aa0dbb9@syzkaller.appspotmail.com rcu: INFO: rcu_sched self-detected stall on CPU rcu: 0-....: (10499 ticks this GP) idle=8ea/1/0x4000000000000002 softirq=1810/1810 fqs=5108 (t=10500 jiffies g=1553 q=595) NMI backtrace for cpu 0 CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.4.0-rc6+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: <IRQ> __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xca/0x13e lib/dump_stack.c:113 nmi_cpu_backtrace.cold+0x55/0x96 lib/nmi_backtrace.c:101 nmi_trigger_cpumask_backtrace+0x1b0/0x1c7 lib/nmi_backtrace.c:62 trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline] rcu_dump_cpu_stacks+0x169/0x1b3 kernel/rcu/tree_stall.h:254 print_cpu_stall kernel/rcu/tree_stall.h:455 [inline] check_cpu_stall kernel/rcu/tree_stall.h:529 [inline] rcu_pending kernel/rcu/tree.c:2795 [inline] rcu_sched_clock_irq.cold+0x4da/0x936 kernel/rcu/tree.c:2244 update_process_times+0x25/0x60 kernel/time/timer.c:1726 tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:167 tick_sched_timer+0x42/0x130 kernel/time/tick-sched.c:1299 __run_hrtimer kernel/time/hrtimer.c:1514 [inline] __hrtimer_run_queues+0x303/0xc60 kernel/time/hrtimer.c:1576 hrtimer_interrupt+0x2e8/0x730 kernel/time/hrtimer.c:1638 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1110 [inline] smp_apic_timer_interrupt+0xf5/0x500 arch/x86/kernel/apic/apic.c:1135 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830 </IRQ> RIP: 0010:hid_apply_multiplier drivers/hid/hid-core.c:1058 [inline] RIP: 0010:hid_setup_resolution_multiplier+0x33b/0x990 drivers/hid/hid-core.c:1114 Code: e8 2a 96 ed fc 48 8d 7d 04 48 89 f8 48 c1 e8 03 42 0f b6 14 38 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 0c 05 00 00 <44> 8b 6d 04 bf 02 00 00 00 44 89 ee e8 64 97 ed fc 41 83 fd 02 74 RSP: 0018:ffff8881da226cd8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffff8450902c RDX: 0000000000000000 RSI: ffffffff84509036 RDI: ffff8881d4df1204 RBP: ffff8881d4df1200 R08: ffff8881da211800 R09: ffffc900004770cc R10: fffff5200009241b R11: ffffc900004920db R12: ffff8881c6640000 R13: 0000000000000000 R14: ffff8881d4df1200 R15: dffffc0000000000 hid_open_report+0x438/0x640 drivers/hid/hid-core.c:1225 hid_parse include/linux/hid.h:1017 [inline] ms_probe+0x12d/0x4d0 drivers/hid/hid-microsoft.c:388 hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2212 really_probe+0x281/0x6d0 drivers/base/dd.c:548 driver_probe_device+0x104/0x210 drivers/base/dd.c:721 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828 bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:430 __device_attach+0x217/0x360 drivers/base/dd.c:894 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:490 device_add+0xae6/0x16f0 drivers/base/core.c:2202 hid_add_device drivers/hid/hid-core.c:2368 [inline] hid_add_device+0x33c/0x9a0 drivers/hid/hid-core.c:2317 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/0x6d0 drivers/base/dd.c:548 driver_probe_device+0x104/0x210 drivers/base/dd.c:721 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828 bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:430 __device_attach+0x217/0x360 drivers/base/dd.c:894 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:490 device_add+0xae6/0x16f0 drivers/base/core.c:2202 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/0x6d0 drivers/base/dd.c:548 driver_probe_device+0x104/0x210 drivers/base/dd.c:721 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828 bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:430 __device_attach+0x217/0x360 drivers/base/dd.c:894 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:490 device_add+0xae6/0x16f0 drivers/base/core.c:2202 usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2537 hub_port_connect drivers/usb/core/hub.c:5184 [inline] hub_port_connect_change drivers/usb/core/hub.c:5324 [inline] port_event drivers/usb/core/hub.c:5470 [inline] hub_event+0x1df8/0x3800 drivers/usb/core/hub.c:5552 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269 process_scheduled_works kernel/workqueue.c:2331 [inline] worker_thread+0x7ab/0xe20 kernel/workqueue.c:2417 kthread+0x318/0x420 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 --- 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. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: INFO: rcu detected stall in hub_event 2019-11-21 14:45 INFO: rcu detected stall in hub_event syzbot @ 2019-11-22 16:51 ` Alan Stern 2019-11-22 21:31 ` Andrey Konovalov 2019-11-23 20:20 ` syzbot 2022-07-30 10:27 ` [syzbot] " syzbot 1 sibling, 2 replies; 18+ messages in thread From: Alan Stern @ 2019-11-22 16:51 UTC (permalink / raw) To: syzbot Cc: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel, linux-usb, syzkaller-bugs On Thu, 21 Nov 2019, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit: 46178223 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=15a05836e00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=99c88c44660624e7 > dashboard link: https://syzkaller.appspot.com/bug?extid=ec5f884c4a135aa0dbb9 > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1061395ae00000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13653d1ce00000 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+ec5f884c4a135aa0dbb9@syzkaller.appspotmail.com > > rcu: INFO: rcu_sched self-detected stall on CPU > RIP: 0010:hid_apply_multiplier drivers/hid/hid-core.c:1058 [inline] > RIP: 0010:hid_setup_resolution_multiplier+0x33b/0x990 > drivers/hid/hid-core.c:1114 Diagnostic patch. #syz test: https://github.com/google/kasan.git 46178223 drivers/hid/hid-core.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) Index: usb-devel/drivers/hid/hid-core.c =================================================================== --- usb-devel.orig/drivers/hid/hid-core.c +++ usb-devel/drivers/hid/hid-core.c @@ -1055,8 +1055,13 @@ static void hid_apply_multiplier(struct */ multiplier_collection = &hid->collection[multiplier->usage->collection_index]; while (multiplier_collection->parent_idx != -1 && - multiplier_collection->type != HID_COLLECTION_LOGICAL) + multiplier_collection->type != HID_COLLECTION_LOGICAL) { + hid_info(hid, "collection %d %px parent %d\n", + multiplier_collection - hid->collection, multiplier_collection, + multiplier_collection->parent_idx); multiplier_collection = &hid->collection[multiplier_collection->parent_idx]; + } + hid_info(hid, "Got collection\n"); effective_multiplier = hid_calculate_multiplier(hid, multiplier); @@ -1069,6 +1074,7 @@ static void hid_apply_multiplier(struct effective_multiplier); } } + hid_info(hid, "Applied multiplier\n"); } /* @@ -1103,16 +1109,23 @@ void hid_setup_resolution_multiplier(str rep_enum = &hid->report_enum[HID_FEATURE_REPORT]; list_for_each_entry(rep, &rep_enum->report_list, list) { + hid_info(hid, "Start report %px maxfield %d\n", + rep, rep->maxfield); for (i = 0; i < rep->maxfield; i++) { /* Ignore if report count is out of bounds. */ if (rep->field[i]->report_count < 1) continue; + hid_info(hid, "Field %d %px maxusage %d\n", + i, rep->field[i], rep->field[i]->maxusage); for (j = 0; j < rep->field[i]->maxusage; j++) { usage = &rep->field[i]->usage[j]; - if (usage->hid == HID_GD_RESOLUTION_MULTIPLIER) + if (usage->hid == HID_GD_RESOLUTION_MULTIPLIER) { + hid_info(hid, "Usage %d %px\n", + j, usage); hid_apply_multiplier(hid, rep->field[i]); + } } } } ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: INFO: rcu detected stall in hub_event 2019-11-22 16:51 ` Alan Stern @ 2019-11-22 21:31 ` Andrey Konovalov 2019-11-25 17:30 ` Alan Stern 2019-11-23 20:20 ` syzbot 1 sibling, 1 reply; 18+ messages in thread From: Andrey Konovalov @ 2019-11-22 21:31 UTC (permalink / raw) To: Alan Stern Cc: syzbot, Benjamin Tissoires, Jiri Kosina, linux-input, LKML, USB list, syzkaller-bugs On Sat, Nov 23, 2019 at 1:51 AM Alan Stern <stern@rowland.harvard.edu> wrote: > > On Thu, 21 Nov 2019, syzbot wrote: > > > Hello, > > > > syzbot found the following crash on: > > > > HEAD commit: 46178223 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=15a05836e00000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=99c88c44660624e7 > > dashboard link: https://syzkaller.appspot.com/bug?extid=ec5f884c4a135aa0dbb9 > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1061395ae00000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13653d1ce00000 > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+ec5f884c4a135aa0dbb9@syzkaller.appspotmail.com > > > > rcu: INFO: rcu_sched self-detected stall on CPU > > > RIP: 0010:hid_apply_multiplier drivers/hid/hid-core.c:1058 [inline] > > RIP: 0010:hid_setup_resolution_multiplier+0x33b/0x990 > > drivers/hid/hid-core.c:1114 I'm not sure, but the stack trace reminds me of this issue, so this report might be related: https://groups.google.com/d/msg/syzkaller-bugs/X0zVbh8aFEM/NsPcshjxBgAJ > > Diagnostic patch. > > #syz test: https://github.com/google/kasan.git 46178223 > > drivers/hid/hid-core.c | 17 +++++++++++++++-- > 1 file changed, 15 insertions(+), 2 deletions(-) > > Index: usb-devel/drivers/hid/hid-core.c > =================================================================== > --- usb-devel.orig/drivers/hid/hid-core.c > +++ usb-devel/drivers/hid/hid-core.c > @@ -1055,8 +1055,13 @@ static void hid_apply_multiplier(struct > */ > multiplier_collection = &hid->collection[multiplier->usage->collection_index]; > while (multiplier_collection->parent_idx != -1 && > - multiplier_collection->type != HID_COLLECTION_LOGICAL) > + multiplier_collection->type != HID_COLLECTION_LOGICAL) { > + hid_info(hid, "collection %d %px parent %d\n", > + multiplier_collection - hid->collection, multiplier_collection, > + multiplier_collection->parent_idx); > multiplier_collection = &hid->collection[multiplier_collection->parent_idx]; > + } > + hid_info(hid, "Got collection\n"); > > effective_multiplier = hid_calculate_multiplier(hid, multiplier); > > @@ -1069,6 +1074,7 @@ static void hid_apply_multiplier(struct > effective_multiplier); > } > } > + hid_info(hid, "Applied multiplier\n"); > } > > /* > @@ -1103,16 +1109,23 @@ void hid_setup_resolution_multiplier(str > > rep_enum = &hid->report_enum[HID_FEATURE_REPORT]; > list_for_each_entry(rep, &rep_enum->report_list, list) { > + hid_info(hid, "Start report %px maxfield %d\n", > + rep, rep->maxfield); > for (i = 0; i < rep->maxfield; i++) { > /* Ignore if report count is out of bounds. */ > if (rep->field[i]->report_count < 1) > continue; > > + hid_info(hid, "Field %d %px maxusage %d\n", > + i, rep->field[i], rep->field[i]->maxusage); > for (j = 0; j < rep->field[i]->maxusage; j++) { > usage = &rep->field[i]->usage[j]; > - if (usage->hid == HID_GD_RESOLUTION_MULTIPLIER) > + if (usage->hid == HID_GD_RESOLUTION_MULTIPLIER) { > + hid_info(hid, "Usage %d %px\n", > + j, usage); > hid_apply_multiplier(hid, > rep->field[i]); > + } > } > } > } > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: INFO: rcu detected stall in hub_event 2019-11-22 21:31 ` Andrey Konovalov @ 2019-11-25 17:30 ` Alan Stern 2019-12-09 18:26 ` Alan Stern 0 siblings, 1 reply; 18+ messages in thread From: Alan Stern @ 2019-11-25 17:30 UTC (permalink / raw) To: Jiri Kosina, Andrey Konovalov Cc: syzbot, Benjamin Tissoires, linux-input, LKML, USB list, syzkaller-bugs Jiri: On Sat, 23 Nov 2019, Andrey Konovalov wrote: > I'm not sure, but the stack trace reminds me of this issue, so this > report might be related: > > https://groups.google.com/d/msg/syzkaller-bugs/X0zVbh8aFEM/NsPcshjxBgAJ No, the issue is quite different, although it is also a bug in the HID parser. The big problem is that the parser assumes all usages will belong to a collection. There's also a second, smaller bug: hid_apply_multipler() assumes every Resolution Multiplier control is associated with a Logical Collection (i.e., there's no way the routine can ever set multiplier_collection to NULL) even though there's a big quotation from the HID Usage Table manual at the start of the function saying that they don't have to be. This bug can be fixed easily, though. The first bug is more troublesome. hid_add_usage() explicitly sets the parser->local.collection_index[] entry to 0 if the current collection stack is empty. But there's no way to distinguish this 0 from a genuine index value that happens to point to the first collection! So what should happen when a usage appears outside of all collections? Is it a bug in the report descriptor (the current code suggests that it is not)? Or should we use a different sentinel value for the collection_index[] entry, one that cannot be confused with a genuine value, such as UINT_MAX? Awaiting your suggestion... Alan Stern ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: INFO: rcu detected stall in hub_event 2019-11-25 17:30 ` Alan Stern @ 2019-12-09 18:26 ` Alan Stern 2019-12-10 21:26 ` [PATCH] HID: Fix slab-out-of-bounds read in hid_field_extract Alan Stern 2024-04-08 16:55 ` INFO: rcu detected stall in hub_event Alan Stern 0 siblings, 2 replies; 18+ messages in thread From: Alan Stern @ 2019-12-09 18:26 UTC (permalink / raw) To: Jiri Kosina, Andrey Konovalov Cc: syzbot, Benjamin Tissoires, linux-input, LKML, USB list, syzkaller-bugs On Mon, 25 Nov 2019, Alan Stern wrote: > Jiri: > > On Sat, 23 Nov 2019, Andrey Konovalov wrote: > > > I'm not sure, but the stack trace reminds me of this issue, so this > > report might be related: > > > > https://groups.google.com/d/msg/syzkaller-bugs/X0zVbh8aFEM/NsPcshjxBgAJ > > No, the issue is quite different, although it is also a bug in the HID > parser. The big problem is that the parser assumes all usages will > belong to a collection. > > There's also a second, smaller bug: hid_apply_multipler() assumes every > Resolution Multiplier control is associated with a Logical Collection > (i.e., there's no way the routine can ever set multiplier_collection to > NULL) even though there's a big quotation from the HID Usage Table > manual at the start of the function saying that they don't have to be. > This bug can be fixed easily, though. > > The first bug is more troublesome. hid_add_usage() explicitly sets the > parser->local.collection_index[] entry to 0 if the current collection > stack is empty. But there's no way to distinguish this 0 from a > genuine index value that happens to point to the first collection! > > So what should happen when a usage appears outside of all collections? > Is it a bug in the report descriptor (the current code suggests that it > is not)? > > Or should we use a different sentinel value for the collection_index[] > entry, one that cannot be confused with a genuine value, such as > UINT_MAX? On Tue, 26 Nov 2019, Jiri Kosina wrote: > Alan, did you get a test result from syzbot on this patch? My mailbox > doesn't seem to have it. On Tue, 26 Nov 2019, syzbot wrote: > Hello, > > syzbot has tested the proposed patch and the reproducer did not trigger > crash: > > Reported-and-tested-by: > syzbot+ec5f884c4a135aa0dbb9@syzkaller.appspotmail.com Jiri: Now we've got the answer. The current question is: What should I do with the patch? It seems rather ad-hoc, not a proper solution to the problem. To refresh your memory, here is the patch that syzbot tested: drivers/hid/hid-core.c | 5 +++++ 1 file changed, 5 insertions(+) Index: usb-devel/drivers/hid/hid-core.c =================================================================== --- usb-devel.orig/drivers/hid/hid-core.c +++ usb-devel/drivers/hid/hid-core.c @@ -1057,6 +1057,8 @@ static void hid_apply_multiplier(struct while (multiplier_collection->parent_idx != -1 && multiplier_collection->type != HID_COLLECTION_LOGICAL) multiplier_collection = &hid->collection[multiplier_collection->parent_idx]; + if (multiplier_collection->type != HID_COLLECTION_LOGICAL) + multiplier_collection = NULL; effective_multiplier = hid_calculate_multiplier(hid, multiplier); @@ -1191,6 +1193,9 @@ int hid_open_report(struct hid_device *d } device->collection_size = HID_DEFAULT_NUM_COLLECTIONS; + /* Needed for usages before the first collection */ + device->collection[0].parent_idx = -1; + ret = -EINVAL; while ((start = fetch_item(start, end, &item)) != NULL) { Alan Stern ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH] HID: Fix slab-out-of-bounds read in hid_field_extract 2019-12-09 18:26 ` Alan Stern @ 2019-12-10 21:26 ` Alan Stern 2019-12-11 14:18 ` Jiri Kosina 2024-04-08 16:55 ` INFO: rcu detected stall in hub_event Alan Stern 1 sibling, 1 reply; 18+ messages in thread From: Alan Stern @ 2019-12-10 21:26 UTC (permalink / raw) To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-input, USB list, syzkaller-bugs The syzbot fuzzer found a slab-out-of-bounds bug in the HID report handler. The bug was caused by a report descriptor which included a field with size 12 bits and count 4899, for a total size of 7349 bytes. The usbhid driver uses at most a single-page 4-KB buffer for reports. In the test there wasn't any problem about overflowing the buffer, since only one byte was received from the device. Rather, the bug occurred when the HID core tried to extract the data from the report fields, which caused it to try reading data beyond the end of the allocated buffer. This patch fixes the problem by rejecting any report whose total length exceeds the HID_MAX_BUFFER_SIZE limit (minus one byte to allow for a possible report index). In theory a device could have a report longer than that, but if there was such a thing we wouldn't handle it correctly anyway. Reported-and-tested-by: syzbot+09ef48aa58261464b621@syzkaller.appspotmail.com Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> --- [as1926] drivers/hid/hid-core.c | 6 ++++++ 1 file changed, 6 insertions(+) Index: usb-devel/drivers/hid/hid-core.c =================================================================== --- usb-devel.orig/drivers/hid/hid-core.c +++ usb-devel/drivers/hid/hid-core.c @@ -268,6 +268,12 @@ static int hid_add_field(struct hid_pars offset = report->size; report->size += parser->global.report_size * parser->global.report_count; + /* Total size check: Allow for possible report index byte */ + if (report->size > (HID_MAX_BUFFER_SIZE - 1) << 3) { + hid_err(parser->device, "report is too long\n"); + return -1; + } + if (!parser->local.usage_index) /* Ignore padding fields */ return 0; ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] HID: Fix slab-out-of-bounds read in hid_field_extract 2019-12-10 21:26 ` [PATCH] HID: Fix slab-out-of-bounds read in hid_field_extract Alan Stern @ 2019-12-11 14:18 ` Jiri Kosina 2019-12-11 15:10 ` Alan Stern 0 siblings, 1 reply; 18+ messages in thread From: Jiri Kosina @ 2019-12-11 14:18 UTC (permalink / raw) To: Alan Stern; +Cc: Benjamin Tissoires, linux-input, USB list, syzkaller-bugs On Tue, 10 Dec 2019, Alan Stern wrote: > The syzbot fuzzer found a slab-out-of-bounds bug in the HID report > handler. The bug was caused by a report descriptor which included a > field with size 12 bits and count 4899, for a total size of 7349 > bytes. > > The usbhid driver uses at most a single-page 4-KB buffer for reports. > In the test there wasn't any problem about overflowing the buffer, > since only one byte was received from the device. Rather, the bug > occurred when the HID core tried to extract the data from the report > fields, which caused it to try reading data beyond the end of the > allocated buffer. > > This patch fixes the problem by rejecting any report whose total > length exceeds the HID_MAX_BUFFER_SIZE limit (minus one byte to allow > for a possible report index). In theory a device could have a report > longer than that, but if there was such a thing we wouldn't handle it > correctly anyway. > > Reported-and-tested-by: syzbot+09ef48aa58261464b621@syzkaller.appspotmail.com > Signed-off-by: Alan Stern <stern@rowland.harvard.edu> > CC: <stable@vger.kernel.org> Thanks for hunting this down Alan. Applied. -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] HID: Fix slab-out-of-bounds read in hid_field_extract 2019-12-11 14:18 ` Jiri Kosina @ 2019-12-11 15:10 ` Alan Stern 2019-12-13 8:44 ` Jiri Kosina 0 siblings, 1 reply; 18+ messages in thread From: Alan Stern @ 2019-12-11 15:10 UTC (permalink / raw) To: Jiri Kosina; +Cc: Benjamin Tissoires, linux-input, USB list, syzkaller-bugs On Wed, 11 Dec 2019, Jiri Kosina wrote: > On Tue, 10 Dec 2019, Alan Stern wrote: > > > The syzbot fuzzer found a slab-out-of-bounds bug in the HID report > > handler. The bug was caused by a report descriptor which included a > > field with size 12 bits and count 4899, for a total size of 7349 > > bytes. > > > > The usbhid driver uses at most a single-page 4-KB buffer for reports. > > In the test there wasn't any problem about overflowing the buffer, > > since only one byte was received from the device. Rather, the bug > > occurred when the HID core tried to extract the data from the report > > fields, which caused it to try reading data beyond the end of the > > allocated buffer. > > > > This patch fixes the problem by rejecting any report whose total > > length exceeds the HID_MAX_BUFFER_SIZE limit (minus one byte to allow > > for a possible report index). In theory a device could have a report > > longer than that, but if there was such a thing we wouldn't handle it > > correctly anyway. > > > > Reported-and-tested-by: syzbot+09ef48aa58261464b621@syzkaller.appspotmail.com > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu> > > CC: <stable@vger.kernel.org> > > Thanks for hunting this down Alan. Applied. I just noticed this code: u8 *hid_alloc_report_buf(struct hid_report *report, gfp_t flags) { /* * 7 extra bytes are necessary to achieve proper functionality * of implement() working on 8 byte chunks */ u32 len = hid_report_len(report) + 7; return kmalloc(len, flags); } Does this indicate that the upper limit on a report length should really be HID_MAX_BUFFER_SIZE - 8 instead of HID_MAX_BUFFER_SIZE - 1? Alan Stern ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] HID: Fix slab-out-of-bounds read in hid_field_extract 2019-12-11 15:10 ` Alan Stern @ 2019-12-13 8:44 ` Jiri Kosina 0 siblings, 0 replies; 18+ messages in thread From: Jiri Kosina @ 2019-12-13 8:44 UTC (permalink / raw) To: Alan Stern; +Cc: Benjamin Tissoires, linux-input, USB list, syzkaller-bugs On Wed, 11 Dec 2019, Alan Stern wrote: > > > The syzbot fuzzer found a slab-out-of-bounds bug in the HID report > > > handler. The bug was caused by a report descriptor which included a > > > field with size 12 bits and count 4899, for a total size of 7349 > > > bytes. > > > > > > The usbhid driver uses at most a single-page 4-KB buffer for reports. > > > In the test there wasn't any problem about overflowing the buffer, > > > since only one byte was received from the device. Rather, the bug > > > occurred when the HID core tried to extract the data from the report > > > fields, which caused it to try reading data beyond the end of the > > > allocated buffer. > > > > > > This patch fixes the problem by rejecting any report whose total > > > length exceeds the HID_MAX_BUFFER_SIZE limit (minus one byte to allow > > > for a possible report index). In theory a device could have a report > > > longer than that, but if there was such a thing we wouldn't handle it > > > correctly anyway. > > > > > > Reported-and-tested-by: syzbot+09ef48aa58261464b621@syzkaller.appspotmail.com > > > Signed-off-by: Alan Stern <stern@rowland.harvard.edu> > > > CC: <stable@vger.kernel.org> > > > > Thanks for hunting this down Alan. Applied. > > I just noticed this code: > > u8 *hid_alloc_report_buf(struct hid_report *report, gfp_t flags) > { > /* > * 7 extra bytes are necessary to achieve proper functionality > * of implement() working on 8 byte chunks > */ > > u32 len = hid_report_len(report) + 7; > > return kmalloc(len, flags); > } > > Does this indicate that the upper limit on a report length should > really be HID_MAX_BUFFER_SIZE - 8 instead of HID_MAX_BUFFER_SIZE - 1? As far as I remember, this is just very lousy way of properly rounding the size up (see 27ce405039bfe). So I believe HID_MAX_BUFFER_SIZE -1 is still functionally correct. Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: INFO: rcu detected stall in hub_event 2019-12-09 18:26 ` Alan Stern 2019-12-10 21:26 ` [PATCH] HID: Fix slab-out-of-bounds read in hid_field_extract Alan Stern @ 2024-04-08 16:55 ` Alan Stern 1 sibling, 0 replies; 18+ messages in thread From: Alan Stern @ 2024-04-08 16:55 UTC (permalink / raw) To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, USB mailing list Jiri and Benjamin: Tracking down an old syzbot report from over four years ago (but still not closed out!) led me to this email thread. It turned out there were two separate bugs involved, one of which has since been fixed. I don't remember the issues very well, so here's a copy of what I wrote back then: On Mon, 09 Dec 2019, Alan Stern wrote: > The big problem is that the parser assumes all usages will > belong to a collection. > > There's also a second, smaller bug: hid_apply_multipler() assumes every > Resolution Multiplier control is associated with a Logical Collection > (i.e., there's no way the routine can ever set multiplier_collection to > NULL) even though there's a big quotation from the HID Usage Table > manual at the start of the function saying that they don't have to be. > This bug can be fixed easily, though. > > The first bug is more troublesome. hid_add_usage() explicitly sets the > parser->local.collection_index[] entry to 0 if the current collection > stack is empty. But there's no way to distinguish this 0 from a > genuine index value that happens to point to the first collection! > > So what should happen when a usage appears outside of all collections? > Is it a bug in the report descriptor (the current code suggests that it > is not)? > > Or should we use a different sentinel value for the collection_index[] > entry, one that cannot be confused with a genuine value, such as > UINT_MAX? Syzbot tested a proposed patch: On Tue, 26 Nov 2019, syzbot wrote: > Hello, > > syzbot has tested the proposed patch and the reproducer did not trigger > crash: > > Reported-and-tested-by: > syzbot+ec5f884c4a135aa0dbb9@syzkaller.appspotmail.com Here is the patch that syzbot tested: drivers/hid/hid-core.c | 5 +++++ 1 file changed, 5 insertions(+) Index: usb-devel/drivers/hid/hid-core.c =================================================================== --- usb-devel.orig/drivers/hid/hid-core.c +++ usb-devel/drivers/hid/hid-core.c @@ -1057,6 +1057,8 @@ static void hid_apply_multiplier(struct while (multiplier_collection->parent_idx != -1 && multiplier_collection->type != HID_COLLECTION_LOGICAL) multiplier_collection = &hid->collection[multiplier_collection->parent_idx]; + if (multiplier_collection->type != HID_COLLECTION_LOGICAL) + multiplier_collection = NULL; effective_multiplier = hid_calculate_multiplier(hid, multiplier); @@ -1191,6 +1193,9 @@ int hid_open_report(struct hid_device *d } device->collection_size = HID_DEFAULT_NUM_COLLECTIONS; + /* Needed for usages before the first collection */ + device->collection[0].parent_idx = -1; + ret = -EINVAL; while ((start = fetch_item(start, end, &item)) != NULL) { The second hunk, addressing the first bug described above, was implemented in commit ea427a222d8b ("HID: core: Fix deadloop in hid_apply_multiplier.") in 2023. But the first hunk, addressing the second bug, is still outstanding. You guys undoubtedly understand this code much better than I do. Is the first hunk in this patch still required? Is it a correct fix for handling Resolution Multiplier controls not associated with any Logical Collection? Alan Stern ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: INFO: rcu detected stall in hub_event 2019-11-22 16:51 ` Alan Stern 2019-11-22 21:31 ` Andrey Konovalov @ 2019-11-23 20:20 ` syzbot 2019-11-24 16:17 ` Alan Stern 1 sibling, 1 reply; 18+ messages in thread From: syzbot @ 2019-11-23 20:20 UTC (permalink / raw) To: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel, linux-usb, stern, syzkaller-bugs Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: INFO: rcu detected stall in hub_event rcu: INFO: rcu_sched self-detected stall on CPU rcu: 1-...!: (10494 ticks this GP) idle=5aa/1/0x4000000000000002 softirq=3913/3913 fqs=1 (t=10500 jiffies g=2825 q=35) rcu: RCU grace-period kthread stack dump: running task 29704 10 2 0x80004000 Call Trace: schedule+0xca/0x250 kernel/sched/core.c:4136 schedule_timeout+0x440/0xb20 kernel/time/timer.c:1895 rcu_gp_fqs_loop kernel/rcu/tree.c:1639 [inline] rcu_gp_kthread+0xaff/0x29e0 kernel/rcu/tree.c:1799 kthread+0x318/0x420 kernel/kthread.c:255 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: nmi_cpu_backtrace.cold+0x55/0x96 lib/nmi_backtrace.c:101 nmi_trigger_cpumask_backtrace+0x1b0/0x1c7 lib/nmi_backtrace.c:62 trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline] rcu_dump_cpu_stacks+0x169/0x1b3 kernel/rcu/tree_stall.h:254 print_cpu_stall kernel/rcu/tree_stall.h:455 [inline] check_cpu_stall kernel/rcu/tree_stall.h:529 [inline] rcu_pending kernel/rcu/tree.c:2795 [inline] rcu_sched_clock_irq.cold+0x4da/0x936 kernel/rcu/tree.c:2244 update_process_times+0x25/0x60 kernel/time/timer.c:1726 tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:167 tick_sched_timer+0x42/0x130 kernel/time/tick-sched.c:1299 __run_hrtimer kernel/time/hrtimer.c:1514 [inline] __hrtimer_run_queues+0x303/0xc60 kernel/time/hrtimer.c:1576 hrtimer_interrupt+0x2e8/0x730 kernel/time/hrtimer.c:1638 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1110 [inline] smp_apic_timer_interrupt+0xf5/0x500 arch/x86/kernel/apic/apic.c:1135 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830 </IRQ> Code: 00 83 fb ff 75 d6 e9 db fc ff ff e8 9d 7b 15 00 e8 68 a8 1a 00 41 56 9d e9 b1 fd ff ff e8 8b 7b 15 00 e8 56 a8 1a 00 41 56 9d <e9> 2a ff ff ff 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 RSP: 0018:ffff8881d932e908 EFLAGS: 00000293 ORIG_RAX: ffffffffffffff13 RDX: 0000000000000000 RSI: ffff8881da24e918 RDI: ffff8881da24e84c R10: fffffbfff11aadad R11: ffffffff88d56d6f R12: 0000000000000045 R13: ffff8881da211800 R14: 0000000000000293 R15: 0000000000000000 dev_vprintk_emit+0x4fc/0x541 drivers/base/core.c:3315 dev_printk_emit+0xba/0xf1 drivers/base/core.c:3326 __dev_printk+0x1db/0x203 drivers/base/core.c:3338 _dev_info+0xd7/0x109 drivers/base/core.c:3384 hid_parse include/linux/hid.h:1017 [inline] ms_probe+0x12d/0x4d0 drivers/hid/hid-microsoft.c:388 hid_device_probe+0x2be/0x3f0 drivers/hid/hid-core.c:2225 driver_probe_device+0x104/0x210 drivers/base/dd.c:721 __device_attach+0x217/0x360 drivers/base/dd.c:894 device_add+0xae6/0x16f0 drivers/base/core.c:2202 hid_add_device drivers/hid/hid-core.c:2381 [inline] hid_add_device+0x33c/0x9a0 drivers/hid/hid-core.c:2330 usb_probe_interface+0x305/0x7a0 drivers/usb/core/driver.c:361 driver_probe_device+0x104/0x210 drivers/base/dd.c:721 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828 bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:430 __device_attach+0x217/0x360 drivers/base/dd.c:894 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 driver_probe_device+0x104/0x210 drivers/base/dd.c:721 __device_attach_driver+0x1c2/0x220 drivers/base/dd.c:828 bus_for_each_drv+0x162/0x1e0 drivers/base/bus.c:430 __device_attach+0x217/0x360 drivers/base/dd.c:894 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:490 device_add+0xae6/0x16f0 drivers/base/core.c:2202 usb_new_device.cold+0x6a4/0xe79 drivers/usb/core/hub.c:2537 hub_port_connect drivers/usb/core/hub.c:5184 [inline] hub_port_connect_change drivers/usb/core/hub.c:5324 [inline] port_event drivers/usb/core/hub.c:5470 [inline] hub_event+0x1df8/0x3800 drivers/usb/core/hub.c:5552 process_one_work+0x92b/0x1530 kernel/workqueue.c:2269 process_scheduled_works kernel/workqueue.c:2331 [inline] worker_thread+0x7ab/0xe20 kernel/workqueue.c:2417 kthread+0x318/0x420 kernel/kthread.c:255 Tested on: commit: 46178223 usb: gadget: add raw-gadget interface git tree: https://github.com/google/kasan.git console output: https://syzkaller.appspot.com/x/log.txt?x=12ee73cee00000 kernel config: https://syzkaller.appspot.com/x/.config?x=99c88c44660624e7 dashboard link: https://syzkaller.appspot.com/bug?extid=ec5f884c4a135aa0dbb9 compiler: gcc (GCC) 9.0.0 20181231 (experimental) patch: https://syzkaller.appspot.com/x/patch.diff?x=14d21c22e00000 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: INFO: rcu detected stall in hub_event 2019-11-23 20:20 ` syzbot @ 2019-11-24 16:17 ` Alan Stern 2019-11-25 9:38 ` syzbot 0 siblings, 1 reply; 18+ messages in thread From: Alan Stern @ 2019-11-24 16:17 UTC (permalink / raw) To: syzbot Cc: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel, linux-usb, syzkaller-bugs Another diagnostic patch. Alan Stern #syz test: https://github.com/google/kasan.git 46178223 Index: usb-devel/drivers/hid/hid-core.c =================================================================== --- usb-devel.orig/drivers/hid/hid-core.c +++ usb-devel/drivers/hid/hid-core.c @@ -175,7 +175,8 @@ static int open_collection(struct hid_pa collection->level = parser->collection_stack_ptr - 1; collection->parent_idx = (collection->level == 0) ? -1 : parser->collection_stack[collection->level - 1]; - + hid_info(parser->device, "New collection %px: idx %d parent %d type %d\n", + collection, (int) collection_index, collection->parent_idx, type); if (type == HID_COLLECTION_APPLICATION) parser->device->maxapplication++; @@ -1046,8 +1047,18 @@ static void hid_apply_multiplier(struct */ multiplier_collection = &hid->collection[multiplier->usage->collection_index]; while (multiplier_collection->parent_idx != -1 && - multiplier_collection->type != HID_COLLECTION_LOGICAL) + multiplier_collection->type != HID_COLLECTION_LOGICAL) { + hid_info(hid, "collection %d %px type %d parent %d\n", + (int) (multiplier_collection - hid->collection), multiplier_collection, + multiplier_collection->type, multiplier_collection->parent_idx); + if (multiplier_collection->parent_idx >= + multiplier_collection - hid->collection) { + hid_info(hid, "BUG: found invalid parent_idx\n"); + return; + } multiplier_collection = &hid->collection[multiplier_collection->parent_idx]; + } + hid_info(hid, "Got collection\n"); effective_multiplier = hid_calculate_multiplier(hid, multiplier); @@ -1060,6 +1071,7 @@ static void hid_apply_multiplier(struct effective_multiplier); } } + hid_info(hid, "Applied multiplier\n"); } /* @@ -1094,16 +1106,23 @@ void hid_setup_resolution_multiplier(str rep_enum = &hid->report_enum[HID_FEATURE_REPORT]; list_for_each_entry(rep, &rep_enum->report_list, list) { + hid_info(hid, "Start report %px maxfield %d\n", + rep, rep->maxfield); for (i = 0; i < rep->maxfield; i++) { /* Ignore if report count is out of bounds. */ if (rep->field[i]->report_count < 1) continue; + hid_info(hid, "Field %d %px maxusage %d\n", + i, rep->field[i], rep->field[i]->maxusage); for (j = 0; j < rep->field[i]->maxusage; j++) { usage = &rep->field[i]->usage[j]; - if (usage->hid == HID_GD_RESOLUTION_MULTIPLIER) + if (usage->hid == HID_GD_RESOLUTION_MULTIPLIER) { + hid_info(hid, "Usage %d %px\n", + j, usage); hid_apply_multiplier(hid, rep->field[i]); + } } } } ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: INFO: rcu detected stall in hub_event 2019-11-24 16:17 ` Alan Stern @ 2019-11-25 9:38 ` syzbot 2019-11-25 21:24 ` Alan Stern 0 siblings, 1 reply; 18+ messages in thread From: syzbot @ 2019-11-25 9:38 UTC (permalink / raw) To: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel, linux-usb, stern, syzkaller-bugs Hello, syzbot has tested the proposed patch but the reproducer still triggered crash: BUG: found invalid parent_idx microsoft 0003:045E:07DA.0001: Field 0 ffff8881c0e00000 maxusage 4899 microsoft 0003:045E:07DA.0001: Usage 72 ffff8881c0e00730 microsoft 0003:045E:07DA.0001: collection 0 ffff8881d91be200 type 0 parent 0 microsoft 0003:045E:07DA.0001: BUG: found invalid parent_idx microsoft 0003:045E:07DA.0001: Start report ffff8881cb82e000 maxfield 1 microsoft 0003:045E:07DA.0001: Field 0 ffff8881c0e00000 maxusage 4899 microsoft 0003:045E:07DA.0001: Usage 72 ffff8881c0e00730 microsoft 0003:045E:07DA.0001: collection 0 ffff8881d91be200 type 0 parent 0 microsoft 0003:045E:07DA.0001: BUG: found invalid parent_idx microsoft 0003:045E:07DA.0001: No inputs registered, leaving microsoft 0003:045E:07DA.0001: hidraw0: USB HID v0.00 Device [HID 045e:07da] on usb-dummy_hcd.5-1/input0 microsoft 0003:045E:07DA.0001: no inputs found microsoft 0003:045E:07DA.0001: could not initialize ff, continuing anyway usb 6-1: USB disconnect, device number 3 Tested on: commit: 46178223 usb: gadget: add raw-gadget interface git tree: https://github.com/google/kasan.git console output: https://syzkaller.appspot.com/x/log.txt?x=14bb93cee00000 kernel config: https://syzkaller.appspot.com/x/.config?x=99c88c44660624e7 dashboard link: https://syzkaller.appspot.com/bug?extid=ec5f884c4a135aa0dbb9 compiler: gcc (GCC) 9.0.0 20181231 (experimental) patch: https://syzkaller.appspot.com/x/patch.diff?x=11c28d5ee00000 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: INFO: rcu detected stall in hub_event 2019-11-25 9:38 ` syzbot @ 2019-11-25 21:24 ` Alan Stern 2019-11-26 7:48 ` Jiri Kosina 2019-11-26 20:21 ` syzbot 0 siblings, 2 replies; 18+ messages in thread From: Alan Stern @ 2019-11-25 21:24 UTC (permalink / raw) To: syzbot Cc: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel, linux-usb, syzkaller-bugs #syz test: https://github.com/google/kasan.git 46178223 Index: usb-devel/drivers/hid/hid-core.c =================================================================== --- usb-devel.orig/drivers/hid/hid-core.c +++ usb-devel/drivers/hid/hid-core.c @@ -1057,6 +1057,8 @@ static void hid_apply_multiplier(struct while (multiplier_collection->parent_idx != -1 && multiplier_collection->type != HID_COLLECTION_LOGICAL) multiplier_collection = &hid->collection[multiplier_collection->parent_idx]; + if (multiplier_collection->type != HID_COLLECTION_LOGICAL) + multiplier_collection = NULL; effective_multiplier = hid_calculate_multiplier(hid, multiplier); @@ -1191,6 +1193,9 @@ int hid_open_report(struct hid_device *d } device->collection_size = HID_DEFAULT_NUM_COLLECTIONS; + /* Needed for usages before the first collection */ + device->collection[0].parent_idx = -1; + ret = -EINVAL; while ((start = fetch_item(start, end, &item)) != NULL) { ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: INFO: rcu detected stall in hub_event 2019-11-25 21:24 ` Alan Stern @ 2019-11-26 7:48 ` Jiri Kosina 2019-11-26 15:18 ` Alan Stern 2019-11-26 20:21 ` syzbot 1 sibling, 1 reply; 18+ messages in thread From: Jiri Kosina @ 2019-11-26 7:48 UTC (permalink / raw) To: Alan Stern Cc: syzbot, andreyknvl, benjamin.tissoires, linux-input, linux-kernel, linux-usb, syzkaller-bugs On Mon, 25 Nov 2019, Alan Stern wrote: > #syz test: https://github.com/google/kasan.git 46178223 Alan, did you get a test result from syzbot on this patch? My mailbox doesn't seem to have it. Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: INFO: rcu detected stall in hub_event 2019-11-26 7:48 ` Jiri Kosina @ 2019-11-26 15:18 ` Alan Stern 0 siblings, 0 replies; 18+ messages in thread From: Alan Stern @ 2019-11-26 15:18 UTC (permalink / raw) To: Jiri Kosina Cc: syzbot, andreyknvl, benjamin.tissoires, linux-input, linux-kernel, linux-usb, syzkaller-bugs On Tue, 26 Nov 2019, Jiri Kosina wrote: > On Mon, 25 Nov 2019, Alan Stern wrote: > > > #syz test: https://github.com/google/kasan.git 46178223 > > Alan, did you get a test result from syzbot on this patch? My mailbox > doesn't seem to have it. No response, not yet. syzbot seems to be very slow testing the patches for this bug report. The earlier ones I submitted also took over a day to finish. BTW, even if this patch fixes the problem, I don't think setting collection[0].parent_idx to -1 is a very good solution. It's brittle and doesn't address the underlying ambiguity. Alan Stern ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: INFO: rcu detected stall in hub_event 2019-11-25 21:24 ` Alan Stern 2019-11-26 7:48 ` Jiri Kosina @ 2019-11-26 20:21 ` syzbot 1 sibling, 0 replies; 18+ messages in thread From: syzbot @ 2019-11-26 20:21 UTC (permalink / raw) To: andreyknvl, benjamin.tissoires, jikos, linux-input, linux-kernel, linux-usb, stern, syzkaller-bugs Hello, syzbot has tested the proposed patch and the reproducer did not trigger crash: Reported-and-tested-by: syzbot+ec5f884c4a135aa0dbb9@syzkaller.appspotmail.com Tested on: commit: 46178223 usb: gadget: add raw-gadget interface git tree: https://github.com/google/kasan.git kernel config: https://syzkaller.appspot.com/x/.config?x=99c88c44660624e7 dashboard link: https://syzkaller.appspot.com/bug?extid=ec5f884c4a135aa0dbb9 compiler: gcc (GCC) 9.0.0 20181231 (experimental) patch: https://syzkaller.appspot.com/x/patch.diff?x=1177cc0ee00000 Note: testing is done by a robot and is best-effort only. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [syzbot] INFO: rcu detected stall in hub_event 2019-11-21 14:45 INFO: rcu detected stall in hub_event syzbot 2019-11-22 16:51 ` Alan Stern @ 2022-07-30 10:27 ` syzbot 1 sibling, 0 replies; 18+ messages in thread From: syzbot @ 2022-07-30 10:27 UTC (permalink / raw) To: andreyknvl, balbi, benjamin.tissoires, fweisbec, gregkh, jikos, linux-input, linux-kernel, linux-usb, mingo, quic_mrana, rafael, stern, syzkaller-bugs, tglx syzbot has bisected this issue to: commit 859bdc359567f5fa8e8dc780d7b5e53ea43d9ce9 Author: Mayank Rana <quic_mrana@quicinc.com> Date: Wed May 18 18:12:52 2022 +0000 usb: dwc3: core: Add error log when core soft reset failed bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=144812f2080000 start commit: 6e2c0490769e Merge tag 'drm-fixes-2022-07-29' of git://ano.. git tree: upstream final oops: https://syzkaller.appspot.com/x/report.txt?x=164812f2080000 console output: https://syzkaller.appspot.com/x/log.txt?x=124812f2080000 kernel config: https://syzkaller.appspot.com/x/.config?x=26034e6fe0075dad dashboard link: https://syzkaller.appspot.com/bug?extid=ec5f884c4a135aa0dbb9 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=119bc436080000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16c3c0f2080000 Reported-by: syzbot+ec5f884c4a135aa0dbb9@syzkaller.appspotmail.com Fixes: 859bdc359567 ("usb: dwc3: core: Add error log when core soft reset failed") For information about bisection process see: https://goo.gl/tpsmEJ#bisection ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2024-04-08 16:55 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-21 14:45 INFO: rcu detected stall in hub_event syzbot 2019-11-22 16:51 ` Alan Stern 2019-11-22 21:31 ` Andrey Konovalov 2019-11-25 17:30 ` Alan Stern 2019-12-09 18:26 ` Alan Stern 2019-12-10 21:26 ` [PATCH] HID: Fix slab-out-of-bounds read in hid_field_extract Alan Stern 2019-12-11 14:18 ` Jiri Kosina 2019-12-11 15:10 ` Alan Stern 2019-12-13 8:44 ` Jiri Kosina 2024-04-08 16:55 ` INFO: rcu detected stall in hub_event Alan Stern 2019-11-23 20:20 ` syzbot 2019-11-24 16:17 ` Alan Stern 2019-11-25 9:38 ` syzbot 2019-11-25 21:24 ` Alan Stern 2019-11-26 7:48 ` Jiri Kosina 2019-11-26 15:18 ` Alan Stern 2019-11-26 20:21 ` syzbot 2022-07-30 10:27 ` [syzbot] " syzbot
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).