Received: by 2002:a05:6359:6284:b0:131:369:b2a3 with SMTP id se4csp2107854rwb; Sun, 6 Aug 2023 09:58:12 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFhETVRdkldgqY2Z7TNUScpmO8FZN6sBrMSVGp6HmezAnJFIWV5HuXliBnWQdq8ax/MD4UR X-Received: by 2002:a17:906:315a:b0:99c:6da0:31d9 with SMTP id e26-20020a170906315a00b0099c6da031d9mr7061694eje.58.1691341092058; Sun, 06 Aug 2023 09:58:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1691341092; cv=none; d=google.com; s=arc-20160816; b=VptfKowQHBldRFjXUIpp+B02VPep91dsIYXW4WuCbjhEJ+u8mUx3kUS6IdDzOQIpNf IGmOPCgl4o98pC9yi6pge4uMgUMNnrqxJQmo/1+ZsUl+rbbKTeYVM5bq7MU10aBhl7wW MmemA9dzIqNLMoqGbXeO3pbsk1/s+sGY5DTgzeFztf8Bw1mE/JtlvjrkdwDmIhfFzqbo HuMEoWulFtw1ob1wdaRmPX3qGniFlfePjQqF6G1HZiIhSKhkxhQR633AjGWJQpYr3tGP 8AzwfKtJw7fEYwUtiokL08F4zSXc8VbEXXlUOZ3tN2FzztGAKUKjwKimjlCvOMonEKHF Sisw== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=geTs1O//wlvl5+cz1gKDGVdI0dnmqxzmjNF4zhJ+ih8=; fh=eOBxEwfb3I7GEM+7A4thmHnVchfumi47Alv7aAR7rqs=; b=xIOhQ1urWIU6Crr9u8qouByX4jTONESUEkLO+j2XYIpwWH1BzQcxxZXINy088el3ol YRqCyOrQRe5Pa05UYX3OgCUZatGTYPBwxdMIwh8ELq9A+7kH948dFDKQCnEzvVk83GQI 95C3pugIb6/oOBnUZTEVeY2hESclbTVJHXft81nlWIo1VhDwgSru4AWxupontYGsaWMH kbiZTu4B8v+BjrfHvx+90jnA1EVZ2+HkvqyGSPhPMNQ2RYzr5nbH03n4vfIOSaLuNKaI ++BizU+8FXxmCPywu5smql38NvY3UE9f+mhIS6GbVeM2IEdN8fcT0xNthMs4Fr6KKaET GdDw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=harvard.edu Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h25-20020a170906399900b0099325282809si4703042eje.572.2023.08.06.09.57.47; Sun, 06 Aug 2023 09:58:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=harvard.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230035AbjHFPP6 (ORCPT + 99 others); Sun, 6 Aug 2023 11:15:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229636AbjHFPP4 (ORCPT ); Sun, 6 Aug 2023 11:15:56 -0400 Received: from netrider.rowland.org (netrider.rowland.org [192.131.102.5]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 10A05114 for ; Sun, 6 Aug 2023 08:15:53 -0700 (PDT) Received: (qmail 96132 invoked by uid 1000); 6 Aug 2023 11:15:51 -0400 Date: Sun, 6 Aug 2023 11:15:51 -0400 From: Alan Stern To: Greg KH Cc: Zhang Shurong , jgross@suse.com, xen-devel@lists.xenproject.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] xen: fix potential shift out-of-bounds in xenhcd_hub_control() Message-ID: <3481a644-1648-4fa9-86eb-2a0b86b8f47a@rowland.harvard.edu> References: <2023062628-shame-ebook-56f2@gregkh> <4825193.GXAFRqVoOG@localhost.localdomain> <2023080659-turban-exemption-1196@gregkh> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2023080659-turban-exemption-1196@gregkh> X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,SPF_HELO_PASS,SPF_PASS autolearn=no 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, Aug 06, 2023 at 04:27:27PM +0200, Greg KH wrote: > On Sun, Aug 06, 2023 at 10:11:43PM +0800, Zhang Shurong wrote: > > 在 2023年7月1日星期六 CST 下午11:51:43,Zhang Shurong 写道: > > > 在 2023年6月26日星期一 CST 下午1:52:02,您写道: > > > > > > > On Mon, Jun 26, 2023 at 07:48:05AM +0200, Jan Beulich wrote: > > > > > On 25.06.2023 18:42, Zhang Shurong wrote: > > > > > > --- a/drivers/usb/host/xen-hcd.c > > > > > > +++ b/drivers/usb/host/xen-hcd.c > > > > > > @@ -456,6 +456,8 @@ static int xenhcd_hub_control(struct usb_hcd *hcd, > > > > > > __u16 typeReq, __u16 wValue,> > > > > > > > > > > > > > info->ports[wIndex - 1].c_connection = > > > > > > false; > > > > > > > > > fallthrough; > > > > > > > > > > > > default: > > > > > > + if (wValue >= 32) > > > > > > + goto error; > > > > > > > > > > > > info->ports[wIndex - 1].status &= ~(1 > > > > > > << wValue); > > > > > > > > Even 31 is out of bounds (as in: UB) as long as it's 1 here rather > > > > > than 1u. > > > > > > > > Why isn't the caller fixed so this type of value could never be passed > > > > to the hub_control callback? > > > > > > > > thanks, > > > > > > > > greg k-h > > > > > > Although I'm not knowledgeable about the USB subsystem, I've observed that > > > not all driver code that implements hub_control callback performs a shift > > > operation on wValue, and not all shift operations among them cause > > > problems. Therefore, I've decided to fix this issue within each driver > > > itself. > > > > > > For example, in r8a66597_hub_control, it will first check whether wValue is > > > valid (always < 31) before the shift operation. In case of an invalid > > > number, the code would execute the error branch instead of the shift > > > operation. > > > > > > switch (wValue) { > > > case USB_PORT_FEAT_ENABLE: > > > rh->port &= ~USB_PORT_STAT_POWER; > > > break; > > > case USB_PORT_FEAT_SUSPEND: > > > break; > > > case USB_PORT_FEAT_POWER: > > > r8a66597_port_power(r8a66597, port, 0); > > > break; > > > case USB_PORT_FEAT_C_ENABLE: > > > case USB_PORT_FEAT_C_SUSPEND: > > > case USB_PORT_FEAT_C_CONNECTION: > > > case USB_PORT_FEAT_C_OVER_CURRENT: > > > case USB_PORT_FEAT_C_RESET: > > > break; > > > default: > > > goto error; > > > } > > > rh->port &= ~(1 << wValue); > > > > Hi there. I apologize for reaching out once more. I'm feeling a bit puzzled > > about what my next step should be. I'm unsure whether I should rewrite this > > patch or attempt to address the issue at the caller level. > > Try addressing it at the caller level first please. If that somehow > does not work, then we will take a patch series that fixes all of the > host controller drivers at once. It's not feasible to fix all the callers, because the calls can come from userspace via usbfs. Alan Stern