Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1346072pxb; Fri, 26 Feb 2021 08:30:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJwe57rKAPat1jm9xXL8QLzyEAki1QGpQpu8OeVOYII5Bcwgv5jJ780KZZbT+EzStn/NQP26 X-Received: by 2002:a05:6402:6c8:: with SMTP id n8mr4315186edy.27.1614357052257; Fri, 26 Feb 2021 08:30:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614357052; cv=none; d=google.com; s=arc-20160816; b=b7DKwdsQeCJcBTDNe6XTAb+RdIOvHB92exYIAZErieRFAub3/v55BqTGD/pUi7fG2t nVj7nOT6iccxFrXskIFypt+iVICz/v/q1mcPkAJ9BtaWxZo/duifOBFwIPZPLUfBlPe8 27lAmOYAbwdkxALkZMSIdwHz0Ol+1AeVV9PLgh+57Ib2z4J3MIsT0TYz7mZJ1XEDr35k +ToqcU7JCVz6IunHr1dPUV7DENBJqgltJrMIe3IZ0dVWtxeJaBl0c69JD5sCxVrhHhVi EEQjGd2GYwXX77fZ5mC8DzKT9U5EPB7iShAhZQeVa1nFGKbfgreUBlNDkidj3zlrW6Oa UL4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=hgCF4vuvqNiJrHT5fVBs1JWKXVoeEk30vIRLeOSrER4=; b=kmIRDkTvyfl1x/ofXgYLPj6LAxVTabhkHWt5SB2Atj8TLu1U4GB+5bZBPRvatjCZl7 RPTVU3QvKFJoAVxSrVKkR1Bn59dNswSetkOoRA+COnSFLMSJDxMJXm1h6gBRWGPRMhu4 NYXXzRXW3/EkLSsscSwyHRERBQTbjn4b9W0RDr5N5F8p8BlW5S9rm8YIkyaTPwh/FRo8 VHW66nxW+bYYl5BERDlMFRE0lvpV4CYxeWQFpY0eYG+/FMJbHw3ejroH/hW68pQ0GnzO IknlCoN2rczN6aGcQf0dzd7fNEQpf4WOqFfWLFhY2c5Jndcy4PD42Bq0QNBRz0HWRKl5 RCMA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c13si6180556ede.559.2021.02.26.08.30.27; Fri, 26 Feb 2021 08:30:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229864AbhBZQ3L (ORCPT + 99 others); Fri, 26 Feb 2021 11:29:11 -0500 Received: from netrider.rowland.org ([192.131.102.5]:33639 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S229769AbhBZQ3I (ORCPT ); Fri, 26 Feb 2021 11:29:08 -0500 Received: (qmail 1393709 invoked by uid 1000); 26 Feb 2021 11:28:21 -0500 Date: Fri, 26 Feb 2021 11:28:21 -0500 From: Alan Stern To: Sabyrzhan Tasbolatov Cc: benjamin.tissoires@redhat.com, jikos@kernel.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, syzbot+ab02336a647181a886a6@syzkaller.appspotmail.com Subject: Re: [PATCH] drivers/hid: fix for the big hid report length Message-ID: <20210226162821.GA1392547@rowland.harvard.edu> References: <20210225155914.GA1350993@rowland.harvard.edu> <20210226081336.3475085-1-snovitoll@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210226081336.3475085-1-snovitoll@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 26, 2021 at 02:13:36PM +0600, Sabyrzhan Tasbolatov wrote: > On Thu, 25 Feb 2021 10:59:14 -0500, Alan Stern wrote: > > Won't this cause silent errors? > > Agree. But there are already such as cases like in: > > // net/bluetooth/hidp/core.c > static void hidp_process_report(..) > { > .. > if (len > HID_MAX_BUFFER_SIZE) > len = HID_MAX_BUFFER_SIZE; > .. > > // drivers/hid/hid-core.c > int hid_report_raw_event(..) > { > .. > rsize = hid_compute_report_size(report); > > if (report_enum->numbered && rsize >= HID_MAX_BUFFER_SIZE) > rsize = HID_MAX_BUFFER_SIZE - 1; > else if (rsize > HID_MAX_BUFFER_SIZE) > rsize = HID_MAX_BUFFER_SIZE; > .. > > // drivers/staging/greybus/hid.c > static int gb_hid_start(..) > { > .. > if (bufsize > HID_MAX_BUFFER_SIZE) > bufsize = HID_MAX_BUFFER_SIZE; > .. > > > How about instead just rejecting any device which includes a report > > whose length is too big (along with an line in the system log explaining > > what's wrong)? > > Not everywhere, but there are already such as logs when > HID_MAX_BUFFER_SIZE > > // drivers/hid/hidraw.c > static ssize_t hidraw_send_report(..) > { > .. > if (count > HID_MAX_BUFFER_SIZE) { > hid_warn(dev, "pid %d passed too large report\n", > task_pid_nr(current)); > ret = -EINVAL; > goto out; > } > > > I've just noticed that hid_compute_report_size() doing the same thing as > hid_report_len(). So I will replace it with latter one with length check. > > So in [PATCH v2] I will do following: > > 1. replace hid_compute_report_size() with hid_report_len() > > 2. in hid_report_len() we can hid_warn() if length > HID_MAX_BUFFER_SIZE, > and return HID_MAX_BUFFER_SIZE. Or we can return 0 in hid_report_len() to let > functions like hid_hw_raw_request(), hid_hw_output_report() to validate > invalid report length and return -EINVAL. Though I'll need to add !length > missing checks in other places. > > Please let me know what it's preferred way in 2nd step. It's been too long since I worked on this stuff; you should check with the maintainers. Another thing to consider: There probably are devices with multiple reports, where one of the reports is too big but people only want to use the other, smaller reports. For situations like that, we don't want to reject the entire device. I don't know if parsing a partiall part is a good thing to do. Alan Stern