* [PATCH] eal/linux: fix undefined allocation of 0 bytes (CERT MEM04-C; CWE-131)
@ 2016-04-27 17:06 Daniel Mrzyglod
2016-06-08 12:42 ` Sergio Gonzalez Monroy
0 siblings, 1 reply; 2+ messages in thread
From: Daniel Mrzyglod @ 2016-04-27 17:06 UTC (permalink / raw)
To: david.marchand, sergio.gonzalez.monroy; +Cc: dev, Daniel Mrzyglod
Fix issue reported by clang scan-build
there is a chance that nr_hugepages will be 0 if conditions for loop
for (i = 0; i < (int) internal_config.num_hugepage_sizes; i++)
will be unmeet.
Fixes: b6a468ad41d5 ("memory: add --socket-mem option")
Signed-off-by: Daniel Mrzyglod <danielx.t.mrzyglod@intel.com>
---
lib/librte_eal/linuxapp/eal/eal_memory.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c
index 5b9132c..e94538e 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -1114,6 +1114,8 @@ rte_eal_hugepage_init(void)
* processing done on these pages, shared memory will be created
* at a later stage.
*/
+ if (nr_hugepages == 0)
+ goto fail;
tmp_hp = malloc(nr_hugepages * sizeof(struct hugepage_file));
if (tmp_hp == NULL)
goto fail;
--
2.5.5
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] eal/linux: fix undefined allocation of 0 bytes (CERT MEM04-C; CWE-131)
2016-04-27 17:06 [PATCH] eal/linux: fix undefined allocation of 0 bytes (CERT MEM04-C; CWE-131) Daniel Mrzyglod
@ 2016-06-08 12:42 ` Sergio Gonzalez Monroy
0 siblings, 0 replies; 2+ messages in thread
From: Sergio Gonzalez Monroy @ 2016-06-08 12:42 UTC (permalink / raw)
To: Daniel Mrzyglod, david.marchand; +Cc: dev
On 27/04/2016 18:06, Daniel Mrzyglod wrote:
> Fix issue reported by clang scan-build
>
> there is a chance that nr_hugepages will be 0 if conditions for loop
> for (i = 0; i < (int) internal_config.num_hugepage_sizes; i++)
> will be unmeet.
>
> Fixes: b6a468ad41d5 ("memory: add --socket-mem option")
>
> Signed-off-by: Daniel Mrzyglod <danielx.t.mrzyglod@intel.com>
> ---
> lib/librte_eal/linuxapp/eal/eal_memory.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c
> index 5b9132c..e94538e 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> @@ -1114,6 +1114,8 @@ rte_eal_hugepage_init(void)
> * processing done on these pages, shared memory will be created
> * at a later stage.
> */
> + if (nr_hugepages == 0)
> + goto fail;
> tmp_hp = malloc(nr_hugepages * sizeof(struct hugepage_file));
> if (tmp_hp == NULL)
> goto fail;
The behavior of malloc(0) is implementation-defined, but on Linux man
page it says that returns NULL.
So strictly speaking, without the patch the outcome is the same cause
malloc(0) will return NULL.
Now, I'd consider the patch not needed but it doesn't really harm either.
Anyone else has comments/thoughts about it?
Regarding the patch itself, I think the title and commit message need to
be modify to reflect that the patch
goal is to handle nr_hugepages = 0 case without relying in malloc to
return NULL.
Sergio
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-06-08 12:42 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-27 17:06 [PATCH] eal/linux: fix undefined allocation of 0 bytes (CERT MEM04-C; CWE-131) Daniel Mrzyglod
2016-06-08 12:42 ` Sergio Gonzalez Monroy
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.