From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id ECD09A0A0C for ; Thu, 15 Apr 2021 08:45:23 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CFE78162049; Thu, 15 Apr 2021 08:45:23 +0200 (CEST) Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by mails.dpdk.org (Postfix) with ESMTP id 24460162049 for ; Thu, 15 Apr 2021 08:45:23 +0200 (CEST) Received: by mail-wr1-f53.google.com with SMTP id s7so22028811wru.6 for ; Wed, 14 Apr 2021 23:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=t8NMiYUfI7YvGr2Pmj+0If/Vhr4MWMmAkNxn2g8x7b4=; b=R32befV2TrFwS+05MfqeLZeu5oR+sPV42GXW0pHCWQSXuvX0saAJktpOOZBYabQbQB OIP8TYz43IRmC0p1pFMMErzZ9kjpLRGaqzpTsScYXUZsp9lwE5AN9WcfMvWDDODulZlz ctFzg49S+GQfid6k/Drs2KPRtkYzQlUXNsIMfpwaQeZBDQ3AIs9N/FgwLJOFhciKSSWL uXHKhuIdVOVuVoxJenrnZcidLpYUisvwsww/1uhbqBtDxL+CQsH6Xlan7+rKNzP73g5w J8xR8FVmTrn4mJc0ffoi5UeFdbpokvrR8/VcS5ihbLGJ8C/77iGSKtrp2CYzwYhCeAw2 WEiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=t8NMiYUfI7YvGr2Pmj+0If/Vhr4MWMmAkNxn2g8x7b4=; b=B5IJEnjechEKrb5UuO54VUJQocRn/S+5KhpV9nlkvihEZZJeSkwq2lsHq34js+Vri9 876blptvWjWjiOkkz1708XabjJ2j75ua4W1PrIG6jCVCC/8fq7f5Vgq8PVLeACzCRgDg ZXdSaDl2jjHzqjT+zw7EDfisupQJRbhCZuy6ycASYFNoPSgfRm6nseanB2qmCl3vMMdm V3GVV/T0M2kPyseBmn+FlUzoWnu1Knv5G63pquNLJYc26wSbkzImxadRC0/LvQVOw/x3 IsrwcHw98m8JI0uc3HK7DgLDQmsEy+pJ8l0eJAA8dp2AaS3zDfemFY13icoixub1SNfL rJVA== X-Gm-Message-State: AOAM532MZaxLmNW1+1ojYJ2bIbnL3o9iIyrfsLqauJaKvaB7x+GRewfC fqskc/xVh7NQiEDq7FxeGZNNKw== X-Google-Smtp-Source: ABdhPJxfyUSSQB+7Bzg8AUn+JUGp9/lTaeD8FmTxKvX/18ZjRcUfyev0PniwItKP+W7APVPlPG+2PA== X-Received: by 2002:adf:ec42:: with SMTP id w2mr566428wrn.373.1618469122856; Wed, 14 Apr 2021 23:45:22 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id v14sm1594086wrd.48.2021.04.14.23.45.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Apr 2021 23:45:22 -0700 (PDT) Date: Thu, 15 Apr 2021 08:45:21 +0200 From: Olivier Matz To: Thomas Monjalon Cc: Wenwu Ma , andrew.rybchenko@oktetlabs.ru, stable@dpdk.org, dev@dpdk.org, aconole@redhat.com, zhihongx.peng@intel.com Message-ID: <20210415064521.GE1650@platinum> References: <20210331210557.4919-1-wenwux.ma@intel.com> <20210413200513.330399-1-wenwux.ma@intel.com> <2483269.apo0RDFAAg@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2483269.apo0RDFAAg@thomas> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-stable] [v2] test/mempool: fix heap buffer overflow X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 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" On Tue, Apr 13, 2021 at 01:52:26PM +0200, Thomas Monjalon wrote: > 13/04/2021 22:05, Wenwu Ma: > > Amount of allocated memory was not enough for mempool > > which cause buffer overflow when access fields of mempool > > private structure in the rte_pktmbuf_priv_size function. > > Was it causing the test to fail? > How do you reproduce the overflow? In the test, right after the rte_mempool_create(), the function rte_mempool_obj_iter() is called too initialize the mempool objects with the rte_pktmbuf_init() callback function. This callback expects that the mempool is a packet pool, i.e. its private area is a struct rte_pktmbuf_pool_private structure. In the current test, the size of the private area is 0, which probably causes the function rte_pktmbuf_priv_size() to return an unpredictable value, and this value is used as a size in a memset. This part of the test was added in commit 923ceaeac140 ("test/mempool: add unit test cases"). Instead of changing the size of the private area like done in the patch, I suggest to use another callback than rte_pktmbuf_init(). After all, this is a mempool test, so we should not rely on mbuf features. The function my_obj_init() could be used like in other places of the test, like this: @@ -552,7 +552,7 @@ test_mempool(void) GOTO_ERR(ret, err); /* test to initialize mempool objects and memory */ - nb_objs = rte_mempool_obj_iter(mp_stack_mempool_iter, rte_pktmbuf_init, + nb_objs = rte_mempool_obj_iter(mp_stack_mempool_iter, my_obj_init, NULL); if (nb_objs == 0) GOTO_ERR(ret, err); Wenwu, does it solve your issue? Regards, Olivier