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=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 8587BC4320E for ; Tue, 31 Aug 2021 13:34:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7173960F92 for ; Tue, 31 Aug 2021 13:34:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237700AbhHaNfg (ORCPT ); Tue, 31 Aug 2021 09:35:36 -0400 Received: from netrider.rowland.org ([192.131.102.5]:57649 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S237489AbhHaNff (ORCPT ); Tue, 31 Aug 2021 09:35:35 -0400 Received: (qmail 366261 invoked by uid 1000); 31 Aug 2021 09:34:38 -0400 Date: Tue, 31 Aug 2021 09:34:38 -0400 From: Alan Stern To: Benjamin Tissoires Cc: Jiri Kosina , syzbot , "open list:HID CORE LAYER" , lkml , Linux USB Mailing List , Michal Kubecek , syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] WARNING in hid_submit_ctrl/usb_submit_urb Message-ID: <20210831133438.GA365946@rowland.harvard.edu> References: <20210819195300.GA8613@rowland.harvard.edu> <000000000000c322ab05c9f2e880@google.com> <20210820140620.GA35867@rowland.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 31, 2021 at 11:51:31AM +0200, Benjamin Tissoires wrote: > On Tue, Aug 24, 2021 at 1:54 PM Jiri Kosina wrote: > > > > 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? > > > > I have finally been able to test this patch: > - the testsuite is still passing (of course, this is not hid-core related) > - Logitech unify receivers are fine (according to the automated tests) > - Gaming mice with hidraw calls works (with libratbag in userspace) > - Wacom Intuos Pro still works (so the usbhid calls to enable the > tablet mode are still OK) > > -> > Tested-by: Benjamin Tissoires > Acked-by: Benjamin Tissoires > > Alan, would you mind resending the patch with the various tags with a > commit description? (unless I missed it...) Will do. I'm rather busy today, so it may have to wait until tomorrow. Alan Stern