linux-kernel - Re: [syzbot] WARNING in hid_submit_ctrl/usb_submit

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]

Date:   Tue, 24 Aug 2021 13:53:56 +0200 (CEST)
From:   Jiri Kosina <jikos@...nel.org>
To:     Alan Stern <stern@...land.harvard.edu>
cc:     syzbot <syzbot+9b57a46bf1801ce2a2ca@...kaller.appspotmail.com>,
        benjamin.tissoires@...hat.com, linux-input@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        mkubecek@...e.cz, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] WARNING in hid_submit_ctrl/usb_submit_urb

On Fri, 20 Aug 2021, Alan Stern wrote:

> > syzbot has tested the proposed patch and the reproducer did not trigger any issue:
> 
> That's good to know.  Still, I suspect there's a better way of handling 
> this condition.
> 
> In particular, does it make sense to accept descriptors for input or 
> feature reports with length zero?  I can't imagine what good such 
> reports would do.

I quickly went through drivers + some hidraw users, and can't spot any use 
case for it.

> On the other hand, I'm not familiar enough with the code to know the 
> right way to reject these descriptors and reports.  It looks like the 
> HID subsystem was not designed with this sort of check in mind.
> 
> Benjamin and Jiri, what do you think?  Is it okay to allow descriptors 
> for zero-length reports and just pretend they have length 1 (as the 
> patch tested by syzbot did), or should we instead reject them during 
> probing?

I think it's a good band-aid for 5.14 (or 5.14-stable if we don't make 
it), and if it turns out to break something (which I don't expect), than 
we can look into rejecting already during probe.

Benjamin, is there a way to run this quickly through your HID regression 
testing machinery?

Thanks,

-- 
Jiri Kosina
SUSE Labs