On Tue, Apr 26, 2016 at 09:44:47AM +0200, Slawomir Mrozowicz wrote:
> Fix issue reported by Coverity.
>
> Coverity ID 13282: Out-of-bounds write
> overrun-local: Overrunning array mcfg->memseg of 256 44-byte elements
> at element index 257 using index j.
>
> Fixes: af75078fece3 ("first public release")
>
> Signed-off-by: Slawomir Mrozowicz <slawomirx.mrozowicz at intel.com>
> ---
> lib/librte_eal/linuxapp/eal/eal_memory.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
> b/lib/librte_eal/linuxapp/eal/eal_memory.c
> index 5b9132c..1e737e4 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> @@ -1333,7 +1333,7 @@ rte_eal_hugepage_init(void)
>
> if (new_memseg) {
> j += 1;
> - if (j == RTE_MAX_MEMSEG)
> + if (j >= RTE_MAX_MEMSEG)
> break;
>
> mcfg->memseg[j].phys_addr = hugepage[i].physaddr;
> --
This does appear to be a valid fix for the issue. However, looking at the code,
it appears that the only way we could actually hit the problem is if
j == RTE_MAX_MEMSEG on exiting the previous loop. Would a check there be a
better
fix for this issue (or perhaps we want both fixes).
Thoughts?
/Bruce
