[dpdk-stable] patch 'mem: fix overflow on allocation' has been queued to LTS release 18.11.9
Kevin Traynor
ktraynor at redhat.com
Fri Jun 5 20:24:21 CEST 2020
Hi,
FYI, your patch has been queued to LTS release 18.11.9
Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 06/10/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.
Queued patches are on a temporary branch at:
https://github.com/kevintraynor/dpdk-stable-queue
This queued commit can be viewed at:
https://github.com/kevintraynor/dpdk-stable-queue/commit/246bd855dff27be510ab98af9629124d3f610cd4
Thanks.
Kevin.
---
>From 246bd855dff27be510ab98af9629124d3f610cd4 Mon Sep 17 00:00:00 2001
From: Bing Zhao <bingz at mellanox.com>
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 <bingz at mellanox.com>
Acked-by: Anatoly Burakov <anatoly.burakov at intel.com>
---
lib/librte_eal/common/malloc_heap.c | 3 +++
test/test/test_malloc.c | 12 ++++++++++++
2 files changed, 15 insertions(+)
diff --git a/lib/librte_eal/common/malloc_heap.c b/lib/librte_eal/common/malloc_heap.c
index b8f26f2b37..de3b73e8c5 100644
--- a/lib/librte_eal/common/malloc_heap.c
+++ b/lib/librte_eal/common/malloc_heap.c
@@ -239,4 +239,7 @@ heap_alloc(struct malloc_heap *heap, const char *type __rte_unused, size_t 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) {
diff --git a/test/test/test_malloc.c b/test/test/test_malloc.c
index 5e52724194..20788011ad 100644
--- a/test/test/test_malloc.c
+++ b/test/test/test_malloc.c
@@ -698,4 +698,16 @@ test_malloc_bad_params(void)
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;
--
2.21.3
---
Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- - 2020-06-05 19:20:52.213127889 +0100
+++ 0024-mem-fix-overflow-on-allocation.patch 2020-06-05 19:20:50.750042176 +0100
@@ -1 +1 @@
-From b341a09c1dd3664b43d5b3a91b6a83136f2d4a12 Mon Sep 17 00:00:00 2001
+From 246bd855dff27be510ab98af9629124d3f610cd4 Mon Sep 17 00:00:00 2001
@@ -5,0 +6,2 @@
+[ upstream commit b341a09c1dd3664b43d5b3a91b6a83136f2d4a12 ]
+
@@ -25 +26,0 @@
-Cc: stable at dpdk.org
@@ -30 +30,0 @@
- app/test/test_malloc.c | 12 ++++++++++++
@@ -31,0 +32 @@
+ test/test/test_malloc.c | 12 ++++++++++++
@@ -34,5 +35,17 @@
-diff --git a/app/test/test_malloc.c b/app/test/test_malloc.c
-index 40a2f500cd..71b3cfdde5 100644
---- a/app/test/test_malloc.c
-+++ b/app/test/test_malloc.c
-@@ -847,4 +847,16 @@ test_malloc_bad_params(void)
+diff --git a/lib/librte_eal/common/malloc_heap.c b/lib/librte_eal/common/malloc_heap.c
+index b8f26f2b37..de3b73e8c5 100644
+--- a/lib/librte_eal/common/malloc_heap.c
++++ b/lib/librte_eal/common/malloc_heap.c
+@@ -239,4 +239,7 @@ heap_alloc(struct malloc_heap *heap, const char *type __rte_unused, size_t 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) {
+diff --git a/test/test/test_malloc.c b/test/test/test_malloc.c
+index 5e52724194..20788011ad 100644
+--- a/test/test/test_malloc.c
++++ b/test/test/test_malloc.c
+@@ -698,4 +698,16 @@ test_malloc_bad_params(void)
@@ -55,12 +67,0 @@
-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
-@@ -242,4 +242,7 @@ heap_alloc(struct malloc_heap *heap, const char *type __rte_unused, size_t 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) {
More information about the stable
mailing list