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 84E2DA0093 for ; Tue, 19 May 2020 15:14:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6DFD81D919; Tue, 19 May 2020 15:14:41 +0200 (CEST) Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 891CB1D702 for ; Tue, 19 May 2020 15:14:40 +0200 (CEST) Received: by mail-wr1-f68.google.com with SMTP id l18so15870108wrn.6 for ; Tue, 19 May 2020 06:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=hObBCYb0m566qf1GCrcH6zsQWxKZoJLFzoI5GLUAaZA=; b=j+EMx4dQJy3DumXtCyZs5Mjn6i+RekdvhVcGjRugOoyj+vdXujRrx5QJ4WheeZIJuG B/Xgc33IoMIs1DDsEf21oGhpsN+L7sDpEJU2OPorgv3H+efms4KG4/v478oi+lF1kfGE Ubr/Qr28py1IsZn1GIFWeo8rWhAPHYYT/SYEpYAKs4tZvG57W2YNItDoboCfXrEuwIlL f06VW8z0bv+FKFhlXkNenxglc2ny/ULff7qlwFRCrl/7gNRRAs0djr+j9M/q/TqdjHLx 046qfDvVIGN61widmjOZYgC+2sTP6hDGw6uGYcpfEBQZBypebyMpWre8TA2XvYYBGFJg BxPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=hObBCYb0m566qf1GCrcH6zsQWxKZoJLFzoI5GLUAaZA=; b=QfpflZzscsjTmZ3J/TziKb+8FRUEPRQhVF2jacB7BraUi6yOvZt+/E4WOK91ZnlE2p XXF75DjaTP3ESMzcGNu+iVIkeSwY0pMM9mSpFKQu4r60cZs/Bl/Y0XOhNFZee0JETc4O m08FYu6jLEw5oyCiUOv7vGB7EmocXLhucFKDUhp149+aS0WwR9DNLSPBX+wIKmxP+p8B SXaVoo309RcDAdM/WTvM1xf02EtRz+vlaR/oNZeso60a+YGCiBvywGLJCMO3ryO7aqUI mCCrrnEnSlSAUNNyhFfVu97tNIbvYrBC7JfK02zpa+ixBgeE+2+9Yid014AvNHaUjxmI 9YSg== X-Gm-Message-State: AOAM530Ht1PuNrr+ADN/Tah9QtGY4th4wJtFn/CMr4V2EQWLUZTcOhqx vPsPrSWOfSpXPYoAjm+8D9k= X-Google-Smtp-Source: ABdhPJzblcwHpzL4Aqj6g3G7xGASUUypWmaAZQz6DePYDHkpebDYRX2PuB/WNqvQVjQJ8VH+LEzxrQ== X-Received: by 2002:a05:6000:1150:: with SMTP id d16mr25786909wrx.197.1589894080225; Tue, 19 May 2020 06:14:40 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id c16sm20570017wrv.62.2020.05.19.06.14.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2020 06:14:39 -0700 (PDT) From: luca.boccassi@gmail.com To: Bing Zhao Cc: Anatoly Burakov , dpdk stable Date: Tue, 19 May 2020 14:05:02 +0100 Message-Id: <20200519130549.112823-167-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200519130549.112823-1-luca.boccassi@gmail.com> References: <20200519125804.104349-1-luca.boccassi@gmail.com> <20200519130549.112823-1-luca.boccassi@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [dpdk-stable] patch 'mem: fix overflow on allocation' has been queued to stable release 19.11.3 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" Hi, FYI, your patch has been queued to stable release 19.11.3 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 05/21/20. So please shout if anyone has objections. Also note that after the patch there's a diff of the upstream commit vs the patch applied to the branch. This will indicate if there was any rebasing needed to apply to the stable branch. If there were code changes for rebasing (ie: not only metadata diffs), please double check that the rebase was correctly done. Thanks. Luca Boccassi --- >From fd554a1f8f2a11739712f6367c0804e0943924a7 Mon Sep 17 00:00:00 2001 From: Bing Zhao Date: Thu, 7 May 2020 16:02:54 +0800 Subject: [PATCH] mem: fix overflow on allocation [ upstream commit b341a09c1dd3664b43d5b3a91b6a83136f2d4a12 ] 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") Signed-off-by: Bing Zhao Acked-by: Anatoly Burakov --- app/test/test_malloc.c | 12 ++++++++++++ lib/librte_eal/common/malloc_heap.c | 3 +++ 2 files changed, 15 insertions(+) diff --git a/app/test/test_malloc.c b/app/test/test_malloc.c index a16e28cc32..57f796f9e5 100644 --- a/app/test/test_malloc.c +++ b/app/test/test_malloc.c @@ -746,6 +746,18 @@ test_malloc_bad_params(void) if (bad_ptr != NULL) goto err_return; + /* rte_malloc expected to return null with size will cause overflow */ + align = RTE_CACHE_LINE_SIZE; + size = (size_t)-8; + + bad_ptr = rte_malloc(type, size, align); + if (bad_ptr != NULL) + goto err_return; + + bad_ptr = rte_realloc(NULL, size, align); + if (bad_ptr != NULL) + goto err_return; + return 0; err_return: diff --git a/lib/librte_eal/common/malloc_heap.c b/lib/librte_eal/common/malloc_heap.c index 842eb9de75..bd5065698d 100644 --- a/lib/librte_eal/common/malloc_heap.c +++ b/lib/librte_eal/common/malloc_heap.c @@ -241,6 +241,9 @@ heap_alloc(struct malloc_heap *heap, const char *type __rte_unused, size_t size, 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); -- 2.20.1 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2020-05-19 14:04:51.314294269 +0100 +++ 0167-mem-fix-overflow-on-allocation.patch 2020-05-19 14:04:44.512653738 +0100 @@ -1,8 +1,10 @@ -From b341a09c1dd3664b43d5b3a91b6a83136f2d4a12 Mon Sep 17 00:00:00 2001 +From fd554a1f8f2a11739712f6367c0804e0943924a7 Mon Sep 17 00:00:00 2001 From: Bing Zhao Date: Thu, 7 May 2020 16:02:54 +0800 Subject: [PATCH] mem: fix overflow on allocation +[ upstream commit b341a09c1dd3664b43d5b3a91b6a83136f2d4a12 ] + 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. @@ -22,7 +24,6 @@ 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 @@ -32,10 +33,10 @@ 2 files changed, 15 insertions(+) diff --git a/app/test/test_malloc.c b/app/test/test_malloc.c -index 40a2f500cd..71b3cfdde5 100644 +index a16e28cc32..57f796f9e5 100644 --- a/app/test/test_malloc.c +++ b/app/test/test_malloc.c -@@ -846,6 +846,18 @@ test_malloc_bad_params(void) +@@ -746,6 +746,18 @@ test_malloc_bad_params(void) if (bad_ptr != NULL) goto err_return;