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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 89370C4338F for ; Fri, 20 Aug 2021 14:06:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7313F600D3 for ; Fri, 20 Aug 2021 14:06:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238353AbhHTOG7 (ORCPT ); Fri, 20 Aug 2021 10:06:59 -0400 Received: from netrider.rowland.org ([192.131.102.5]:58539 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S235032AbhHTOG6 (ORCPT ); Fri, 20 Aug 2021 10:06:58 -0400 Received: (qmail 36556 invoked by uid 1000); 20 Aug 2021 10:06:20 -0400 Date: Fri, 20 Aug 2021 10:06:20 -0400 From: Alan Stern To: syzbot Cc: benjamin.tissoires@redhat.com, jikos@kernel.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, mkubecek@suse.cz, syzkaller-bugs@googlegroups.com Subject: Re: [syzbot] WARNING in hid_submit_ctrl/usb_submit_urb Message-ID: <20210820140620.GA35867@rowland.harvard.edu> References: <20210819195300.GA8613@rowland.harvard.edu> <000000000000c322ab05c9f2e880@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000000000000c322ab05c9f2e880@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org On Thu, Aug 19, 2021 at 05:40:07PM -0700, syzbot wrote: > Hello, > > 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. 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? Alan Stern