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 C0809A0350 for ; Mon, 11 May 2020 16:53:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 840941C197; Mon, 11 May 2020 16:53:07 +0200 (CEST) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by dpdk.org (Postfix) with ESMTP id ED5591BF46 for ; Mon, 11 May 2020 16:53:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589208785; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6JVTt4jmnftyNzXa5uCZWba/mOz2I7HlRQXue11WP74=; b=RnbAiyaDb/jj+dexDuOP5oSMl0BeEKQXW/qaNyEHdiFxbYakW0UdprkMwPEWBB88o0i26C ICucYyp/P1JoM5H4c6m4hv5lS1s6Ym6ff4f018t7wZ+9A/KRtjL9IbfgLuVSKFfhNY05zl QF80fhph4XStWBP468Z5cEKsYIETpXI= Received: from mail-ua1-f69.google.com (mail-ua1-f69.google.com [209.85.222.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-238-wqaY55IvPw-pSr3WQeV6cA-1; Mon, 11 May 2020 10:53:03 -0400 X-MC-Unique: wqaY55IvPw-pSr3WQeV6cA-1 Received: by mail-ua1-f69.google.com with SMTP id g28so4515961uaf.15 for ; Mon, 11 May 2020 07:53:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6JVTt4jmnftyNzXa5uCZWba/mOz2I7HlRQXue11WP74=; b=gSdlYf/XjqgmCM90WojlbBFkmx2Ot79dY6i211yBIMoctrrXxWfWX+sNnaawVd0MEu x0Qtd2g7JhoLJVVMyvJjHmYowtIk/PiU8IQ0jblNcqtrNh/mY0fD6r3m1dNzqMm69NAE aUr39EbbRtrKZNC8BgS9MJwrf4Rn48iTzKWH74OW0rVODyR0M3X1mQ+tDnbNaUpjmfAs 34LQ2XxwV7Xo5/MTXrUcwOswbT6FN46OrZ/5BTRbviIrX1mAT7+lIO5TrIHhxOULKcJ9 PnW4ydRf7cV84DCqJv/P6gyxScIe0JDtcKDF6sL9QT6daZgIfUJ6Ybtik8huF9l/6/3j akwQ== X-Gm-Message-State: AOAM53136PwA0VNAyC4Dcbw+7MHeEVjdcyXsHl+1hC1NGM4EHSR9/p8K /QU5Gw9upIrcTzb/LuSyhJCUYvyFK32VAdDg7TfQU3S8lhBJeN9g/PipBBen2IyJ97vnl3ZnmHv RmO8bZaeHdzdnb9CeB+dGxlc= X-Received: by 2002:ac5:c8a1:: with SMTP id o1mr1883336vkl.56.1589208782945; Mon, 11 May 2020 07:53:02 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwm3V8aoAlI6JxwkDIZLCZipNoqEhbQXRDnLnBAw5bpnxs3W5Bps4Jslql9jS/pAhVHrIMhj9bXri6TTR/MJAU= X-Received: by 2002:ac5:c8a1:: with SMTP id o1mr1883305vkl.56.1589208782628; Mon, 11 May 2020 07:53:02 -0700 (PDT) MIME-Version: 1.0 References: <1588837269-360196-1-git-send-email-bingz@mellanox.com> <1588838574-361500-1-git-send-email-bingz@mellanox.com> In-Reply-To: <1588838574-361500-1-git-send-email-bingz@mellanox.com> From: David Marchand Date: Mon, 11 May 2020 16:52:51 +0200 Message-ID: To: Bing Zhao Cc: "Burakov, Anatoly" , Thomas Monjalon , dev , dpdk stable X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v3] mem: fix the alloc size roundup overflow X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" On Thu, May 7, 2020 at 10:03 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: stable@dpdk.org > > Signed-off-by: Bing Zhao Acked-by: Anatoly Burakov Applied, thanks. -- David Marchand