linux-kernel - Re: INFO: rcu detected stall in hub

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1911251216350.1565-100000@iolanthe.rowland.org>
Date:   Mon, 25 Nov 2019 12:30:12 -0500 (EST)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Jiri Kosina <jikos@...nel.org>,
        Andrey Konovalov <andreyknvl@...gle.com>
cc:     syzbot <syzbot+ec5f884c4a135aa0dbb9@...kaller.appspotmail.com>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        <linux-input@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
        USB list <linux-usb@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: INFO: rcu detected stall in hub_event

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