From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E002C43603 for ; Mon, 9 Dec 2019 18:26:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id DBE422077B for ; Mon, 9 Dec 2019 18:26:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726483AbfLIS0b (ORCPT ); Mon, 9 Dec 2019 13:26:31 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:37368 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726365AbfLIS0b (ORCPT ); Mon, 9 Dec 2019 13:26:31 -0500 Received: (qmail 4869 invoked by uid 2102); 9 Dec 2019 13:26:30 -0500 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Dec 2019 13:26:30 -0500 Date: Mon, 9 Dec 2019 13:26:30 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Jiri Kosina , Andrey Konovalov cc: syzbot , Benjamin Tissoires , , LKML , USB list , syzkaller-bugs Subject: Re: INFO: rcu detected stall in hub_event In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-input-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org 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