Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp663566yba; Thu, 18 Apr 2019 07:36:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqx1pueAVTG+YKWV97t20UfVLRJUx8zsv1bXCBXMQe6f3dL5mzJwaK4wljWRHnTg+wpGO1Yw X-Received: by 2002:a65:518d:: with SMTP id h13mr11284428pgq.259.1555598218216; Thu, 18 Apr 2019 07:36:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555598218; cv=none; d=google.com; s=arc-20160816; b=G1K0A1vXqvAhMfEXlgplJhrNyKvMVyspfdVIM94llhDwxOeJL+4c7GMytTLy8U9Rni 3fXsa38mccS0RqDdOUesDOVvR3FDyjxX9+RxS4Iqe0dcAPABuOA9QRIZTX3XSIRn8uJ4 WdYkvQURH1Dl+MP2yKTH07pgSahznGcReCDgqea8ozmUg4+YnDPiySgq5clPtwKnqXhp Apk4G1XDvD9WqNUxQw5guXhw6ir0JzdxsGDC+dEcJ5tmCG8d8zrKzIXGFweLmWWSBLey BN16Pb2k9FCSbQJCDwGIfemrpKHPXqJkqyzyNT7uU90s+fUVybu17VLtNGMgp6mU+QHt jROA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=x66TzDpLqifJN1EpjW+UQylWemtfXnFeLUYgSn44dlE=; b=M+7rall1NLzmo3fz38/wXVL2Ay+4165xl5qck6Hef/KhC98czdqsdYjOT3fOAx4l3B s8/Srdz/NLL1eDtqvMVdNavc3GrOFDyNgblaFPiaoXpZzBuMlnVVq7uv2pR5G/qMuhww lc9V/r82TS+QdjxdkP664jciJn0T/kBPxXlZQ1ltu27ZHuYNCRi/PzeZRpZRrqLA/myx NWZOZsAmY4eRKvZa574RL0XqAoHFKdr2ilfLDECiHQPGB5gd2VWberjV9Hf5iIDH2Frr 5vItu2eEdgDY5yF/LvPELsZnVwIRlBqLvxkF3FDmhEqoYdkDniWUPde30D3KmQpGhLBC c1+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i64si1893129pge.179.2019.04.18.07.36.43; Thu, 18 Apr 2019 07:36:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388685AbfDROdx (ORCPT + 99 others); Thu, 18 Apr 2019 10:33:53 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:50312 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S2388097AbfDROdx (ORCPT ); Thu, 18 Apr 2019 10:33:53 -0400 Received: (qmail 3140 invoked by uid 2102); 18 Apr 2019 10:33:52 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Apr 2019 10:33:52 -0400 Date: Thu, 18 Apr 2019 10:33:52 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: "zhuyan (M)" cc: Greg KH , "anton@enomsg.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v2] usb:host: fix divide-by-zero in function fhci_queue_urb In-Reply-To: <2e3a7b4df8744b508b866db40bb8cf28@huawei.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 18 Apr 2019, zhuyan (M) wrote: > > > @@ -765,11 +765,12 @@ void fhci_queue_urb(struct fhci_hcd *fhci, > > > struct urb *urb) > > > > > > switch (ed->mode) { > > > case FHCI_TF_BULK: > > > + max_pkt_size = usb_endpoint_maxp(&urb->ep->desc); > > > if (urb->transfer_flags & URB_ZERO_PACKET && > > > urb->transfer_buffer_length > 0 && > > > + (max_pkt_size != 0) && > > > > Now you shouldn't need to add this extra test. > > > > Alan Stern > But the return value of usb_endpoint_maxp() may be 0. > Do we need to take protective measures? Yes, we do. But the protective measures don't belong in the fhci driver. They should go in core/config.c:usb_parse_endpoint(). That routine already has code to check for maxpacket sizes that are too large; you can add code that checks for maxpacket sizes that are too small. In theory an interrupt or isochronous endpoint might have maxpacket set to 0 -- we could warn about these and accept them -- but this is not allowed for bulk endpoints (see section 5.8.3 of the USB 2.0 specification). In fact, bulk endpoints are not allowed to have maxpacket size smaller than 8. Maybe if you make this change then fhci-hcd won't need any modifications at all. Alan Stern