Message ID | 20221128083627.1199512-1-harshit.m.mogalapalli@oracle.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp5518785wrr; Mon, 28 Nov 2022 00:45:38 -0800 (PST) X-Google-Smtp-Source: AA0mqf5CL8RBKv28+TMKSD12BfSZlKf+xMNcc6YQumVClXQZBQZMOj1dBdw1XogQO1bMBaJJoqvK X-Received: by 2002:a05:6a00:1f10:b0:573:578b:e773 with SMTP id be16-20020a056a001f1000b00573578be773mr34430589pfb.11.1669625138626; Mon, 28 Nov 2022 00:45:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669625138; cv=none; d=google.com; s=arc-20160816; b=Jw9q9UD3SQj6UBnGR72ScNgEPrUQDwqBbPET3zkjRs5VCia9UmGe6mwPg4dKlfqBWT nLoCYh3X0Q5XpMf5Ki+S7EVjv+Cms9rNbG6ckqPbabYzkLQuxGZQ3n/MOMupfGynS085 JFg03v18s/S+2JbuZkawZn8ZUe5BGp2+GexRZDX/vmqVZ5vPjgS+/6Lozw25bxHy2Jzx pERHGc12Qh9D5PjHxhwDPtylhonr2WwESbbEtkjgy2shN21lhhTnwP9sjZCISEi+GWlo lv5ARRQdrQsvdsgc8hUULEhd5z/JKBLTqfnDo5+9tcOJXqib8jVj/ROQ/v0BcLIAe2J5 Uj1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:content-transfer-encoding:mime-version :message-id:date:subject:cc:from:dkim-signature; bh=BlyfctjrhD2WjrvyRQMuxTcpb5Ak/tstUQ1VYEeBsUI=; b=prK2gk9VuCmJvlMxiFYq7sWZzsM4zvh6SavDTTKCFPJDjXxraveRm5FgxFZZ0HXeqC 0ploPOpMpA/1Wq32afkRmeb27COE14XP2/oSknBtpS9mTHdRSf+A38fN0338vVFsoSG1 uyuYbeWtmVMi28OasX1GJY+UtrkC87owig3WYrugAT9HfFHp+wmHmboAj5IVBXnuO92Y BA9+A96doNpl07uOh2zXGfr4DWuMbjxcnYoG2nwE/mIH6NCYJT1i8LDf+Lswn1rXLUaP vy22mqZOKA/15Ygv6DNZoJJb3pFtGxbG8ywOGV3DIgMH6IErqy713vekX3F1oZBaodZy TNzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@oracle.com header.s=corp-2022-7-12 header.b=McNpOTcU; 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=oracle.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id w17-20020a170902e89100b001873af01dcasi12206092plg.85.2022.11.28.00.45.25; Mon, 28 Nov 2022 00:45:38 -0800 (PST) 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; dkim=fail header.i=@oracle.com header.s=corp-2022-7-12 header.b=McNpOTcU; 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=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230042AbiK1Igq (ORCPT <rfc822;gah0developer@gmail.com> + 99 others); Mon, 28 Nov 2022 03:36:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229670AbiK1Igo (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 28 Nov 2022 03:36:44 -0500 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 185796257 for <linux-kernel@vger.kernel.org>; Mon, 28 Nov 2022 00:36:42 -0800 (PST) Received: from pps.filterd (m0246632.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2AS6aSXD005159; Mon, 28 Nov 2022 08:36:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding; s=corp-2022-7-12; bh=BlyfctjrhD2WjrvyRQMuxTcpb5Ak/tstUQ1VYEeBsUI=; b=McNpOTcUIs/413GVUQI6h+pjzHHVX8G+HPfZUCAiVC/jzyzHVIi9FNT+a+Pc5TJ+5C+A t3wlKYIl/VE+LF0+W2lxKSYYzu0X35GiCnf0EhbiLM9W+Dtk19Gt64Yv3cP6O1JfmITq B73KgMgKeD/vpvbefv1G6XTVYJXnvjYCoj+WldLG6iSMR42SAyu76xxgJVOOzo01FOxv 6p2j7zVem3c4A0ed9zoJQKS3REbe/AfPsEku/V52MjAZIkpQnwgFf9pUscBoRbJczohO hGd//kEgow5yC7/96+BZUwjTau+mRoDDrhROhxlFzPb6AlNYuLDzl+dRhDaKJ7oCxaxz Eg== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3m3adt2mx1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Nov 2022 08:36:36 +0000 Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 2AS82haq022363; Mon, 28 Nov 2022 08:36:36 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3m3c1swbup-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 28 Nov 2022 08:36:36 +0000 Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2AS8Y33l040816; Mon, 28 Nov 2022 08:36:35 GMT Received: from ca-dev112.us.oracle.com (ca-dev112.us.oracle.com [10.129.136.47]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id 3m3c1swbtt-1; Mon, 28 Nov 2022 08:36:35 +0000 From: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Cc: harshit.m.mogalapalli@oracle.com, error27@gmail.com, harshit.m.mogalapalli@gmail.com, "Michael S . Tsirkin" <mst@redhat.com>, Jason Wang <jasowang@redhat.com>, Xie Yongji <xieyongji@bytedance.com>, Gautam Dawar <gautam.dawar@xilinx.com>, Parav Pandit <parav@nvidia.com>, Eli Cohen <elic@nvidia.com>, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org Subject: [PATCH v2] vduse: Validate vq_num in vduse_validate_config() Date: Mon, 28 Nov 2022 00:36:26 -0800 Message-Id: <20221128083627.1199512-1-harshit.m.mogalapalli@oracle.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-28_07,2022-11-25_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 suspectscore=0 bulkscore=0 adultscore=0 mlxlogscore=999 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211280066 X-Proofpoint-ORIG-GUID: zvnDFjPhaAWWyzLgPXFYjnWjiTSpB54y X-Proofpoint-GUID: zvnDFjPhaAWWyzLgPXFYjnWjiTSpB54y X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net To: unlisted-recipients:; (no To-header on input) Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750728849240266680?= X-GMAIL-MSGID: =?utf-8?q?1750728849240266680?= |
Series |
[v2] vduse: Validate vq_num in vduse_validate_config()
|
|
Commit Message
Harshit Mogalapalli
Nov. 28, 2022, 8:36 a.m. UTC
Add a limit to 'config->vq_num' which is user controlled data which
comes from an vduse_ioctl to prevent large memory allocations.
This is found using static analysis with smatch.
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
---
v1->v2: Change title of the commit and description, add a limit to
vq_num.
Note: I think here 0xffff is the max size of vring = no: of vqueues.
Only compile and boot tested.
---
drivers/vdpa/vdpa_user/vduse_dev.c | 3 +++
1 file changed, 3 insertions(+)
Comments
On Mon, Nov 28, 2022 at 12:36:26AM -0800, Harshit Mogalapalli wrote: >Add a limit to 'config->vq_num' which is user controlled data which >comes from an vduse_ioctl to prevent large memory allocations. > >This is found using static analysis with smatch. > >Suggested-by: Michael S. Tsirkin <mst@redhat.com> >Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> >--- >v1->v2: Change title of the commit and description, add a limit to > vq_num. > >Note: I think here 0xffff is the max size of vring = no: of vqueues. >Only compile and boot tested. >--- > drivers/vdpa/vdpa_user/vduse_dev.c | 3 +++ > 1 file changed, 3 insertions(+) > >diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c >index 35dceee3ed56..31017ebc4d7c 100644 >--- a/drivers/vdpa/vdpa_user/vduse_dev.c >+++ b/drivers/vdpa/vdpa_user/vduse_dev.c >@@ -1440,6 +1440,9 @@ static bool vduse_validate_config(struct vduse_dev_config *config) > if (config->config_size > PAGE_SIZE) > return false; > >+ if (config->vq_num > 0xffff) What about using U16_MAX here? Thanks, Stefano >+ return false; >+ > if (!device_is_allowed(config->device_id)) > return false; > >-- >2.38.1 >
On Mon, Nov 28, 2022 at 11:53:12AM +0100, Stefano Garzarella wrote: > On Mon, Nov 28, 2022 at 12:36:26AM -0800, Harshit Mogalapalli wrote: > > Add a limit to 'config->vq_num' which is user controlled data which > > comes from an vduse_ioctl to prevent large memory allocations. > > > > This is found using static analysis with smatch. > > > > Suggested-by: Michael S. Tsirkin <mst@redhat.com> > > Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> > > --- > > v1->v2: Change title of the commit and description, add a limit to > > vq_num. > > > > Note: I think here 0xffff is the max size of vring = no: of vqueues. > > Only compile and boot tested. > > --- > > drivers/vdpa/vdpa_user/vduse_dev.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c > > index 35dceee3ed56..31017ebc4d7c 100644 > > --- a/drivers/vdpa/vdpa_user/vduse_dev.c > > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c > > @@ -1440,6 +1440,9 @@ static bool vduse_validate_config(struct vduse_dev_config *config) > > if (config->config_size > PAGE_SIZE) > > return false; > > > > + if (config->vq_num > 0xffff) > > What about using U16_MAX here? Where is the ->vq_num stored in a u16? I looked for this but didn't see it. regards, dan carpenter
On Mon, Nov 28, 2022 at 01:58:00PM +0300, Dan Carpenter wrote: >On Mon, Nov 28, 2022 at 11:53:12AM +0100, Stefano Garzarella wrote: >> On Mon, Nov 28, 2022 at 12:36:26AM -0800, Harshit Mogalapalli wrote: >> > Add a limit to 'config->vq_num' which is user controlled data which >> > comes from an vduse_ioctl to prevent large memory allocations. >> > >> > This is found using static analysis with smatch. >> > >> > Suggested-by: Michael S. Tsirkin <mst@redhat.com> >> > Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> >> > --- >> > v1->v2: Change title of the commit and description, add a limit to >> > vq_num. >> > >> > Note: I think here 0xffff is the max size of vring = no: of vqueues. >> > Only compile and boot tested. >> > --- >> > drivers/vdpa/vdpa_user/vduse_dev.c | 3 +++ >> > 1 file changed, 3 insertions(+) >> > >> > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c >> > index 35dceee3ed56..31017ebc4d7c 100644 >> > --- a/drivers/vdpa/vdpa_user/vduse_dev.c >> > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c >> > @@ -1440,6 +1440,9 @@ static bool vduse_validate_config(struct vduse_dev_config *config) >> > if (config->config_size > PAGE_SIZE) >> > return false; >> > >> > + if (config->vq_num > 0xffff) >> >> What about using U16_MAX here? > >Where is the ->vq_num stored in a u16? I looked for this but didn't >see it. I thought vq_num referred to the number of elements in the vq (like .get_vq_num_max), since this patch wants to limit to 0xffff. But it actually refers to the number of virtqueue, so @Harshit why do we limit it to 0xffff? Maybe we should explain it in the commit message or in a comment. Thanks, Stefano
On 28/11/22 4:43 pm, Stefano Garzarella wrote: > On Mon, Nov 28, 2022 at 01:58:00PM +0300, Dan Carpenter wrote: >> On Mon, Nov 28, 2022 at 11:53:12AM +0100, Stefano Garzarella wrote: >>> On Mon, Nov 28, 2022 at 12:36:26AM -0800, Harshit Mogalapalli wrote: >>> > Add a limit to 'config->vq_num' which is user controlled data which >>> > comes from an vduse_ioctl to prevent large memory allocations. >>> > >>> > This is found using static analysis with smatch. >>> > >>> > Suggested-by: Michael S. Tsirkin <mst@redhat.com> >>> > Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> >>> > --- >>> > v1->v2: Change title of the commit and description, add a limit to >>> > vq_num. >>> > >>> > Note: I think here 0xffff is the max size of vring = no: of vqueues. >>> > Only compile and boot tested. >>> > --- >>> > drivers/vdpa/vdpa_user/vduse_dev.c | 3 +++ >>> > 1 file changed, 3 insertions(+) >>> > >>> > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c >>> b/drivers/vdpa/vdpa_user/vduse_dev.c >>> > index 35dceee3ed56..31017ebc4d7c 100644 >>> > --- a/drivers/vdpa/vdpa_user/vduse_dev.c >>> > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c >>> > @@ -1440,6 +1440,9 @@ static bool vduse_validate_config(struct >>> vduse_dev_config *config) >>> > if (config->config_size > PAGE_SIZE) >>> > return false; >>> > >>> > + if (config->vq_num > 0xffff) >>> >>> What about using U16_MAX here? >> >> Where is the ->vq_num stored in a u16? I looked for this but didn't >> see it. > > I thought vq_num referred to the number of elements in the vq (like > .get_vq_num_max), since this patch wants to limit to 0xffff. > > But it actually refers to the number of virtqueue, so @Harshit why do we > limit it to 0xffff? > Hi Stefano, I may be incorrect about the details of this driver, my v1 was purely based on static analysis, Micheal suggested me to put a limit of 0xffff on vq_num. I really don't know about the driver, while I was searching other parts of code, I thought 0xffff is based vring size, I have asked the same question on v1 today. Ref to v1: https://lore.kernel.org/all/82e8ce27-0743-59bf-fbe8-a25093167451@oracle.com/ > Maybe we should explain it in the commit message or in a comment. > yeah, we should clarify the limit in commit message, once Micheal shares about the limit '0xffff), I will add those details and send a next version if that's okay. Thanks, Harshit > Thanks, > Stefano >
On Mon, Nov 28, 2022 at 12:13:10PM +0100, Stefano Garzarella wrote: > On Mon, Nov 28, 2022 at 01:58:00PM +0300, Dan Carpenter wrote: > > On Mon, Nov 28, 2022 at 11:53:12AM +0100, Stefano Garzarella wrote: > > > On Mon, Nov 28, 2022 at 12:36:26AM -0800, Harshit Mogalapalli wrote: > > > > Add a limit to 'config->vq_num' which is user controlled data which > > > > comes from an vduse_ioctl to prevent large memory allocations. > > > > > > > > This is found using static analysis with smatch. > > > > > > > > Suggested-by: Michael S. Tsirkin <mst@redhat.com> > > > > Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> > > > > --- > > > > v1->v2: Change title of the commit and description, add a limit to > > > > vq_num. > > > > > > > > Note: I think here 0xffff is the max size of vring = no: of vqueues. > > > > Only compile and boot tested. > > > > --- > > > > drivers/vdpa/vdpa_user/vduse_dev.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c > > > > index 35dceee3ed56..31017ebc4d7c 100644 > > > > --- a/drivers/vdpa/vdpa_user/vduse_dev.c > > > > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c > > > > @@ -1440,6 +1440,9 @@ static bool vduse_validate_config(struct vduse_dev_config *config) > > > > if (config->config_size > PAGE_SIZE) > > > > return false; > > > > > > > > + if (config->vq_num > 0xffff) > > > > > > What about using U16_MAX here? > > > > Where is the ->vq_num stored in a u16? I looked for this but didn't > > see it. > > I thought vq_num referred to the number of elements in the vq (like > .get_vq_num_max), since this patch wants to limit to 0xffff. > > But it actually refers to the number of virtqueue, so @Harshit why do we > limit it to 0xffff? > > Maybe we should explain it in the commit message or in a comment. > > Thanks, > Stefano This limit is somewhat arbitrary. However, currently virtio pci and ccw are limited to a 16 bit vq number. While MMIO isn't it is also isn't used with lots of VQs due to current lack of support for per-vq interrupts. Thus, the 0xffff limit on number of VQs corresponding to a 16-bit VQ number seems sufficient for now. Feel free to put the above in a code comment.
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c index 35dceee3ed56..31017ebc4d7c 100644 --- a/drivers/vdpa/vdpa_user/vduse_dev.c +++ b/drivers/vdpa/vdpa_user/vduse_dev.c @@ -1440,6 +1440,9 @@ static bool vduse_validate_config(struct vduse_dev_config *config) if (config->config_size > PAGE_SIZE) return false; + if (config->vq_num > 0xffff) + return false; + if (!device_is_allowed(config->device_id)) return false;