Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp5605443rdb; Sun, 17 Sep 2023 04:36:29 -0700 (PDT) X-Google-Smtp-Source: AGHT+IE92N/T92zHZG0wLnWu5Um1CXjHiP307eMOwYmA00G3bj33b9VGvKTSP1ltT4TNjcG2eA5m X-Received: by 2002:a05:6a00:139b:b0:690:41a1:9b6a with SMTP id t27-20020a056a00139b00b0069041a19b6amr8401458pfg.5.1694950588890; Sun, 17 Sep 2023 04:36:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694950588; cv=none; d=google.com; s=arc-20160816; b=nPdFGdAHHhiJjK3xBPvtCEODNHOeW/C9xQ25392ds8FAEmxu/k7TdL7MXALATDV20M lt2Z+F02FxUskdPUe/nbC1JARBSyKK0CTHKaSl2hjLVVIhlxHx0ola/L3LbhicJGVhZV H+HSEYqh4qruepWIzYvWTrCFqlNyeirEbCjEtu72X8FLB6Na7lUzdEHZSM/hHKkKSVwa YaylGmMJ08mDHyRt+no8Bee8Jdx9dEJXQdtpVXbVkNh7r9PuDZLkupjX3yd6O/24BR9V nt7k9NYZeZV3Zy0IrtAoVWrsr/tO4V2WQ0SSGZiz9IrDkJaoGE6T+Z8pxii+s6u2oj9A r1nw== 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:dkim-signature; bh=DbGBLj/Z5PK1oQmdnqE5DmhPyx1KGSvGq1QfJvHUZsg=; fh=yZnYZUSgd2N5M5O03IEpTNqhe2Rq8XbtaXtTSKKS8ps=; b=DFF2rX7kP+GlWCLRS0J6KPBWgURL/IDIDtllWZO/06DwqAjD7GCt/yR1TNS6yAYJ3P 2arSnTaz6jr/Yeh9J/UC8r181YMsa4y+LuwUx0rxAyIxc/wSiuJEYOj1JA/nG9mMbesb bRXgtpzcm+7WHpzgc1eHYR/huVQPxYtvDaee6gZMjsJmMs0IJC9ReS+W3duXRiAtAcs0 lxngmT6X56NgTyd8uMT5s/vck06Uzww4GbQgcWICQYjLpzqhG7chcIu2WkiwGrsri4EN xBB1t+boAviOzLZ/v+mjYUGcE3uTZNqzdrv1dpOCFPHp8/kwRCHJUPbSn0JAxYgYN9mP xzxA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="LubuApJ/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 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 agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id cj25-20020a056a00299900b0068fa57cc15bsi6497978pfb.124.2023.09.17.04.36.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 17 Sep 2023 04:36:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="LubuApJ/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 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 out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 3A22E819D1F4; Sun, 17 Sep 2023 01:05:49 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231907AbjIQIFO (ORCPT + 99 others); Sun, 17 Sep 2023 04:05:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34316 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231518AbjIQIEx (ORCPT ); Sun, 17 Sep 2023 04:04:53 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2EEB3127; Sun, 17 Sep 2023 01:04:48 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70B4AC433C7; Sun, 17 Sep 2023 08:04:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1694937887; bh=1h5LcJ03IUO48wVxTPxjCPe7OlWV58gb87QmcYg6uuQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=LubuApJ/ahdQUlJAbFGW/avEpTKbuPb8jGK4Wmih51twXHgNZZk1kPJrrv6amXOlH 3vDGAz1HYb2NwvCM6Z7H1vthBFQ625vewD2Zz9PUWde4UWw1/RmyK9DdXLFqRfZbTo LK+FHdpQZBoQfzlfaKrj2G1Gv0vo5YuEGfFPisS4= Date: Sun, 17 Sep 2023 10:04:44 +0200 From: Greg Kroah-Hartman To: Krishna Kurapati Cc: Linyu Yuan , Maciej =?utf-8?Q?=C5=BBenczykowski?= , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, quic_ppratap@quicinc.com, quic_wcheng@quicinc.com, quic_jackp@quicinc.com, stable@vger.kernel.org Subject: Re: [PATCH v2] usb: gadget: ncm: Handle decoding of multiple NTB's in unwrap call Message-ID: <2023091743-tightly-drivable-4360@gregkh> References: <20230915061001.18884-1-quic_kriskura@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230915061001.18884-1-quic_kriskura@quicinc.com> X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Sun, 17 Sep 2023 01:05:49 -0700 (PDT) On Fri, Sep 15, 2023 at 11:39:48AM +0530, Krishna Kurapati wrote: > When NCM is used with hosts like Windows PC, it is observed that there are > multiple NTB's contained in one usb request giveback. Since the driver > unwraps the obtained request data assuming only one NTB is present, we loose > the subsequent NTB's present resulting in data loss. > > Fix this by checking the parsed block length with the obtained data length > in usb request and continue parsing after the last byte of current NTB. > > Cc: stable@vger.kernel.org What commit id does this fix? > Reviewed-by: Maciej Żenczykowski > Signed-off-by: Krishna Kurapati > --- > drivers/usb/gadget/function/f_ncm.c | 26 +++++++++++++++++++------- > 1 file changed, 19 insertions(+), 7 deletions(-) > > diff --git a/drivers/usb/gadget/function/f_ncm.c b/drivers/usb/gadget/function/f_ncm.c > index feccf4c8cc4f..f00f051438ec 100644 > --- a/drivers/usb/gadget/function/f_ncm.c > +++ b/drivers/usb/gadget/function/f_ncm.c > @@ -1156,7 +1156,8 @@ static int ncm_unwrap_ntb(struct gether *port, > struct sk_buff_head *list) > { > struct f_ncm *ncm = func_to_ncm(&port->func); > - __le16 *tmp = (void *) skb->data; > + unsigned char *ntb_ptr = (void *) skb->data; Why persist with the extra ' ', didn't checkpatch complain about this? And why the cast at all? > + __le16 *tmp; > unsigned index, index2; > int ndp_index; > unsigned dg_len, dg_len2; > @@ -1169,6 +1170,10 @@ static int ncm_unwrap_ntb(struct gether *port, > const struct ndp_parser_opts *opts = ncm->parser_opts; > unsigned crc_len = ncm->is_crc ? sizeof(uint32_t) : 0; > int dgram_counter; > + int to_process = skb->len; > + > +parse_ntb: > + tmp = (void *) ntb_ptr; Again, no blank space please. And why the cast? thanks, greg k-h