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 B6CD4A0561; Mon, 20 Apr 2020 13:39:55 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A05541C23D; Mon, 20 Apr 2020 13:39:54 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 7675D1C22F; Mon, 20 Apr 2020 13:39:52 +0200 (CEST) IronPort-SDR: 1GHwm7OxVGYdKXMcGIpYVT9ZoGX2OkIeRC9gbAdBp2ovniHQDiEKKpgNorOFF59py8Mv587Gge m2OwLilp4KnQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2020 04:39:51 -0700 IronPort-SDR: 3BBCP0lqg9yiz1cY8TbsGxawiInvKt+NsOYl8QSpe4c8sj5zznaG7ZvOg+y+cVXHYqF0wTYmGO IRQ2cswNp8IQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,406,1580803200"; d="scan'208";a="246872694" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.193.28]) ([10.213.193.28]) by fmsmga008.fm.intel.com with ESMTP; 20 Apr 2020 04:39:50 -0700 To: Bing Zhao Cc: dev@dpdk.org, sergio.gonzalez.monroy@intel.com, stable@dpdk.org References: <1586256364-185699-1-git-send-email-bingz@mellanox.com> From: "Burakov, Anatoly" Message-ID: <88ce7ff0-27f7-9cf0-13bf-b66795bd64cd@intel.com> Date: Mon, 20 Apr 2020 12:39:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <1586256364-185699-1-git-send-email-bingz@mellanox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] mem: fix the alloc size roundup overflow 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 07-Apr-20 11:46 AM, Bing Zhao wrote: > The size checking is done in the caller. The size parameter is an > unsigned (64b wide) right now, so the comparison with zero should be > enough in most cases. But it won't help in the following case. > If the allocating request input a huge number by mistake, e.g., some > overflow after the calculation (especially subtraction), the checking > in the caller will succeed since it is not zero. Indeed, there is not > enough space in the system to support such huge memory allocation. > Usually it will return failure in the following code. But if the > input size is just a little smaller than the UINT64_MAX, like -2 in > signed type. > The roundup will cause an overflow and then "reset" the size to 0, > and then only a header (128B now) with zero length will be returned. > The following will be the previous allocation header. > It should be OK in most cases if the application won't access the > memory body. Or else, some critical issue will be caused and not easy > to debug. So this issue should be prevented at the beginning, like > other big size failure, NULL pointer should be returned also. > > Fixes: fdf20fa7bee9 ("add prefix to cache line macros") > Cc: sergio.gonzalez.monroy@intel.com > Cc: stable@dpdk.org > > Signed-off-by: Bing Zhao > --- > lib/librte_eal/common/malloc_heap.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/lib/librte_eal/common/malloc_heap.c b/lib/librte_eal/common/malloc_heap.c > index 842eb9d..bd50656 100644 > --- a/lib/librte_eal/common/malloc_heap.c > +++ b/lib/librte_eal/common/malloc_heap.c > @@ -241,6 +241,9 @@ > size = RTE_CACHE_LINE_ROUNDUP(size); > align = RTE_CACHE_LINE_ROUNDUP(align); > > + /* roundup might cause an overflow */ > + if (size == 0) > + return NULL; > elem = find_suitable_element(heap, size, flags, align, bound, contig); > if (elem != NULL) { > elem = malloc_elem_alloc(elem, size, align, bound, contig); > Can we add a unit test for this in malloc_autotest? Otherwise, Acked-by: Anatoly Burakov -- Thanks, Anatoly