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 8B381C4320A 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 684B5610E6 for ; Fri, 20 Aug 2021 14:06:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240575AbhHTOG7 (ORCPT ); Fri, 20 Aug 2021 10:06:59 -0400 Received: from netrider.rowland.org ([192.131.102.5]:54675 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S238353AbhHTOG6 (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-input@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