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 23C4FA0350; Mon, 11 May 2020 16:53:10 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A470D1C1BB; Mon, 11 May 2020 16:53:09 +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 761761BF46 for ; Mon, 11 May 2020 16:53:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589208787; 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=Re4RKSlditJVwBBJXYuuqqxXJKASunjZWiCMva/BLgDk8E91UIh4MQMAIAjhbDz5HK5wZC EnHs1eNxARgwqi2rfWWKjFudgpyVLbCY8m7Enc3kN2LKL4WqRxEuggzOCn0ej0Vm7Flc57 oBy+uLygVfWIMuWXYo1GyXICQWvjZ9E= Received: from mail-vk1-f198.google.com (mail-vk1-f198.google.com [209.85.221.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-234-CUrqQeFRNEyavRa-H-UwSA-1; Mon, 11 May 2020 10:53:03 -0400 X-MC-Unique: CUrqQeFRNEyavRa-H-UwSA-1 Received: by mail-vk1-f198.google.com with SMTP id y3so2716153vkl.17 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=A1n1qvcpfJ7lpivEcyhZ1ZKfJLAgXbQoXoJNDI/87zVnlwS9V+EIeVffi1P+Se68nm cJFZEcsC7dhQsJI1fOtDwVQryWOYI7dgLO6Wbt1+zuUzDtiAWwO6TMNmnjP5VyFqk6bj pNKGWytDFTuFHEx4QlUR/0fQpjCHDllkAlfh5xiSgTFAvYfn9IKFMBWgIyUQcvsR48r8 KyqAHcl6Bn/EVjXni+oe2izQ3mO2d/fbn7PoOAO+BTZDZN3mhRK+SOMuB8Vjj5HTsvDC RyhDcn3TpPoNcKeyEjgpXIP1lz1Z08SrfaXPsc48pWngTwF8AA84t2UHDcw4SroSIW7E HmQg== X-Gm-Message-State: AOAM532Cx5TdZl3ylYAP56w2jgIVHipX2j/expIA1kHYP7JhGmidRymb tNQeIo3XqIKvCFGZ4QVUvVTf6zFNI3HFfG8e9tdsgMEjKqvvSsqW2tSOIh4Ut7SmSWbG6TwuwYo TVaRlGC4cGuwbiYlMR/4= X-Received: by 2002:ac5:c8a1:: with SMTP id o1mr1883333vkl.56.1589208782943; 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-dev] [PATCH v3] 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 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