Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp2056627ioo; Mon, 23 May 2022 09:08:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxL5Yi2TbxQ04hnj2RpC+kAfyhdfeyJZk7Ay9Irhp5Co9ZIxvbiSOs8Y+OQk4O2D73+EWVO X-Received: by 2002:a17:90b:1a8a:b0:1e0:3630:19f0 with SMTP id ng10-20020a17090b1a8a00b001e0363019f0mr9496197pjb.89.1653322122245; Mon, 23 May 2022 09:08:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653322122; cv=none; d=google.com; s=arc-20160816; b=ON3d5xfC7JEklGRij2Lr8UxDPtqHeuca6mrbTfF/Hnx+qXRt4ni9Ah/KKjN3VRCsIv 7fxt/mgRV2So31lhzuhvtHUM9yQ22k8r/XK0kGhdMe7epJNVuQziXbqB63oA/kdBqBBU Csi4gjy8nx/iigl39v5TUCcM7+dzO9fpIFyrW1DcED3Rlc0qtuwjFRkKkCaee64Eya28 g1LOCcSgwaD34wxmCJVmrksRTu5j4lpDjp5zchfcwekAAekElXTPaskqKXdo0Jp8p1C5 rqF2ifB488UsROlWVSGDkoHEgb9I9kK2kmyk4Te90O9xesUY2Tl6fTSLi+M6/2lK3Lbl wicQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=FM+v6uvcw7VSjT/r5F3zhIow/0uNhFX7f6gV+AtO6q4=; b=w5m63SznGxz5drHhZNqymkcPmzhLStzWHldinAtAJO2ErkjAIlo3I03jVAksgjW7ZS e9g5nC7OnMSe8FPYOihsqGrgGv5Vm+zemg6s48tz0uD3nT7nC5eSEBOeb8KVpqJqbiqy orDFc2K5lQhxWm2208AdeD84nVjR+QyQh7/dE0olHJoaP5645JH5FHk/+vFbBSfnz3VC M9iqRz72Rpn6aht0+rabaZao2ROKFgWwbgjwIcg67AIjjR5AAeIVPCxdOKzv51De0wrT r/UiaO8nNGUQbTmHnlGHo36g8zb4S4S4PVJh42cRnj6hqgoEEEKWXauXYV3Z8O/IiZPm WHsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="r/Cq1M52"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id k7-20020a170902c40700b0015abefdc1f1si12258071plk.285.2022.05.23.09.08.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 May 2022 09:08:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="r/Cq1M52"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 24E08644D8; Mon, 23 May 2022 09:08:35 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238500AbiEWQHK (ORCPT + 99 others); Mon, 23 May 2022 12:07:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238387AbiEWQHH (ORCPT ); Mon, 23 May 2022 12:07:07 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ECBBE22BF3 for ; Mon, 23 May 2022 09:06:58 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8EA35B81192 for ; Mon, 23 May 2022 16:06:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C1A1EC385AA; Mon, 23 May 2022 16:06:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1653322016; bh=qyIyPX6ADZ1zEeCUptE8kITzDG/Coxms3dWlBd9Ao8I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=r/Cq1M528dfKuwMUBnpcrF0W2aVzTWOBDppAGmjEzZvjT34Jpaqi5FCb5rOIJmVrO ZOdDM9d5bDLbI1U/KwtuTJiX8SVfbkp62JwkuGfWg05kyUo0yeIEr2wQuZojxwSGPh qvZHKG0HwTGIlQ9FWTlOekAxZWbYlEhRZRaaA91s= Date: Mon, 23 May 2022 18:06:53 +0200 From: Greg KH To: Zheyu Ma Cc: eli.billauer@gmail.com, arnd@arndb.de, Linux Kernel Mailing List Subject: Re: [PATCH v2] char: xillybus: Check endpoint type before allocing Message-ID: References: <20220514114819.2773691-1-zheyuma97@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 22, 2022 at 01:06:59PM +0800, Zheyu Ma wrote: > On Fri, May 20, 2022 at 1:41 PM Greg KH wrote: > > > > On Fri, May 20, 2022 at 11:32:51AM +0800, Zheyu Ma wrote: > > > On Sat, May 14, 2022 at 9:32 PM Greg KH wrote: > > > > > > > > On Sat, May 14, 2022 at 07:48:19PM +0800, Zheyu Ma wrote: > > > > > The driver submits bulk urb without checking the endpoint type is > > > > > actually bulk. > > > > > > > > > > [ 3.108690] usb 1-1: BOGUS urb xfer, pipe 3 != type 1 > > > > > [ 3.108983] WARNING: CPU: 0 PID: 211 at drivers/usb/core/urb.c:503 usb_submit_urb+0xcd9/0x18b0 > > > > > [ 3.110976] RIP: 0010:usb_submit_urb+0xcd9/0x18b0 > > > > > [ 3.115318] Call Trace: > > > > > [ 3.115452] > > > > > [ 3.115570] try_queue_bulk_in+0x43c/0x6e0 [xillyusb] > > > > > [ 3.115838] xillyusb_probe+0x488/0x1230 [xillyusb] > > > > > > > > > > Add a check in endpoint_alloc() to fix the bug. > > > > > > > > > > Signed-off-by: Zheyu Ma > > > > > --- > > > > > Changes in v2: > > > > > - Check the endpoint type at probe time > > > > > --- > > > > > drivers/char/xillybus/xillyusb.c | 27 ++++++++++++++++++++++++++- > > > > > 1 file changed, 26 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/char/xillybus/xillyusb.c b/drivers/char/xillybus/xillyusb.c > > > > > index dc3551796e5e..4467f13993ef 100644 > > > > > --- a/drivers/char/xillybus/xillyusb.c > > > > > +++ b/drivers/char/xillybus/xillyusb.c > > > > > @@ -167,6 +167,7 @@ struct xillyusb_dev { > > > > > struct device *dev; /* For dev_err() and such */ > > > > > struct kref kref; > > > > > struct workqueue_struct *workq; > > > > > + struct usb_interface *intf; > > > > > > > > > > int error; > > > > > spinlock_t error_lock; /* protect @error */ > > > > > @@ -475,6 +476,25 @@ static void endpoint_dealloc(struct xillyusb_endpoint *ep) > > > > > kfree(ep); > > > > > } > > > > > > > > > > +static int xillyusb_check_endpoint(struct xillyusb_dev *xdev, u8 ep_num) > > > > > +{ > > > > > + struct usb_host_interface *if_desc = xdev->intf->altsetting; > > > > > + int i; > > > > > + > > > > > + for (i = 0; i < if_desc->desc.bNumEndpoints; i++) { > > > > > + struct usb_endpoint_descriptor *ep = &if_desc->endpoint[i].desc; > > > > > + > > > > > + if (ep->bEndpointAddress != ep_num) > > > > > + continue; > > > > > + > > > > > + if ((usb_pipein(ep_num) && usb_endpoint_is_bulk_in(ep)) || > > > > > + (usb_pipeout(ep_num) && usb_endpoint_is_bulk_out(ep))) > > > > > + return 0; > > > > > + } > > > > > > > > Why not use the built-in usb core functions that do this for you instead > > > > of hand-parsing this? Look at usb_find_common_endpoints() and related > > > > functions, that should make this much easier. > > > > > > Thanks for your reminder. But in this driver, we have to check not > > > only the type and direction of the endpoint, but also the address of > > > it. And the endpoint's address is sometimes dynamic. For example, in > > > the function xillyusb_open(): > > > > > > out_ep = endpoint_alloc(xdev, (chan->chan_idx + 2) | USB_DIR_OUT, > > > bulk_out_work, BUF_SIZE_ORDER, BUFNUM); > > > > > > However, usb_find_common_endpoints() can only find the first endpoint > > > that satisfies the condition, not on a specific address. I cannot find > > > a more suitable built-in core function, please correct me if I'm > > > wrong. > > > > I do not understand the problem here, it looks like your code above that > > I responded to doesn't care about specific addresses at all. It is just > > walking all of them and making sure that it is a bulk in/out endpoint. > > Please correct me if I'm wrong. I think the driver needs to check if > the urb has the correct type before submitting the urb, and this check > should be done early. Yes, very very early, like probe() callback time early. Not way down here in "do we want to allow open() to work or not" like you are currently doing. If the device does not have the EXACT USB endpoints that you are expecting (size, address, direction, type, etc.) at probe time reject the device. That is what the helper functions I pointed you at are for. This driver is trying to detect this type of problem _way_ too late. thanks, greg k-h