From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4EF0EA051A; Fri, 17 Jan 2020 08:52:09 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 87FA11D16D; Fri, 17 Jan 2020 08:52:07 +0100 (CET) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 2D3D91D169; Fri, 17 Jan 2020 08:52:04 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jan 2020 23:51:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,329,1574150400"; d="scan'208";a="373581422" Received: from dpdk-virtio-tbie-2.sh.intel.com (HELO ___) ([10.67.104.74]) by orsmga004.jf.intel.com with ESMTP; 16 Jan 2020 23:51:37 -0800 Date: Fri, 17 Jan 2020 15:51:35 +0800 From: Tiwei Bie To: Maxime Coquelin Cc: dev@dpdk.org, zhihong.wang@intel.com, stable@dpdk.org, Ilja Van Sprundel Message-ID: <20200117075134.GA219619@___> References: <20200116104427.3810-1-maxime.coquelin@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200116104427.3810-1-maxime.coquelin@redhat.com> User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [PATCH] vhost: catch overflow causing mmap of size 0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Jan 16, 2020 at 11:44:27AM +0100, Maxime Coquelin wrote: > This patch catches an overflow that could happen if an > invalid region size or page alignement is provided by the s/alignement/alignment/ > guest via the VHOST_USER_SET_MEM_TABLE request. > > If the sum of the size to mmap and the alignment overflows > uint64_t, then RTE_ALIGN_CEIL(mmap_size, alignment) macro > will return 0. This value was passed as is as size argument > to mmap(). > > While kernel handling of mmap() syscall returns an error > if size is 0, it is better to catch it earlier and provide > a meaningful error log. > > Fixes: ec09c280b839 ("vhost: fix mmap not aligned with hugepage size") > Cc: stable@dpdk.org > > Reported-by: Ilja Van Sprundel > Signed-off-by: Maxime Coquelin > --- > lib/librte_vhost/vhost_user.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/lib/librte_vhost/vhost_user.c b/lib/librte_vhost/vhost_user.c > index 0b7d1e288e..41ec069cb6 100644 > --- a/lib/librte_vhost/vhost_user.c > +++ b/lib/librte_vhost/vhost_user.c > @@ -1145,6 +1145,21 @@ vhost_user_set_mem_table(struct virtio_net **pdev, struct VhostUserMsg *msg, > goto err_mmap; > } > mmap_size = RTE_ALIGN_CEIL(mmap_size, alignment); > + if (mmap_size == 0) { > + /* > + * It could happen if initial mmap_size + alignment > + * overflows the sizeof uint64, which could happen if > + * either mmap_size or alignment value is wrong. > + * > + * mmap() kernel implementation would return an error, > + * but better catch it before and provide useful info > + * in the logs. > + */ > + VHOST_LOG_CONFIG(ERR, "mmap size (0x%" PRIx64 ") " > + "or alignment (0x%" PRIx64 ") is invalid\n", > + reg->size + mmap_offset, alignment); > + goto err_mmap; > + } > > populate = (dev->dequeue_zero_copy) ? MAP_POPULATE : 0; > mmap_addr = mmap(NULL, mmap_size, PROT_READ | PROT_WRITE, > -- > 2.21.0 Reviewed-by: Tiwei Bie