I missed this patch at the time!
On 27/04/2016 12:29, 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 | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c
> b/lib/librte_eal/linuxapp/eal/eal_memory.c
> index 5b9132c..715bd52 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_memory.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
> @@ -1333,8 +1333,11 @@ rte_eal_hugepage_init(void)
>
> if (new_memseg) {
> j += 1;
> - if (j == RTE_MAX_MEMSEG)
> + if (j >= RTE_MAX_MEMSEG) {
> + RTE_LOG(ERR, EAL,
> + "Failed: memseg reached
> RTE_MAX_MEMSEG\n");
> break;
> + }
>
> mcfg->memseg[j].phys_addr = hugepage[i].physaddr;
> mcfg->memseg[j].addr = hugepage[i].final_va;
As Bruce was suggesting in his comment to the v1, it's more helpful to
do a check before the loop
and print a message distinguishing the error case, something along the
lines of: "all memsegs
used by ivshmem. Please either increase....", returning with -ENOMEM error.
Sergio
