From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 50F65A0C3F;
Thu, 15 Apr 2021 14:51:38 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 2367C162277;
Thu, 15 Apr 2021 14:51:38 +0200 (CEST)
Received: from us-smtp-delivery-124.mimecast.com
(us-smtp-delivery-124.mimecast.com [216.205.24.124])
by mails.dpdk.org (Postfix) with ESMTP id 807A5162276
for <dev@dpdk.org>; Thu, 15 Apr 2021 14:51:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1618491095;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=caJJuRDYyllFxub50pyILf6za+ef3FqyavxD8dfNhYc=;
b=KtEOEPexCgrUa3ZUcPyyNDeiMHdJpmlhEW3OSmo7HV81J3FA4Gn+7r6qRGCu4VqkXPc9iQ
zxFkOHe4lAYyfQSSHA71g2PY30Jrz6dmc0NytxBz65ur1+CsWipyMmxCYnr7S/FUmwnhc/
G1EZZi/U/5d/Ze5SQVp+eGFAstijJ60=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
[209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
us-mta-325-9f9SfSTbPkeC7-zyibQ4Cw-1; Thu, 15 Apr 2021 08:51:32 -0400
X-MC-Unique: 9f9SfSTbPkeC7-zyibQ4Cw-1
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com
[10.5.11.15])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5EDCE1898281;
Thu, 15 Apr 2021 12:51:30 +0000 (UTC)
Received: from dhcp-25.97.bos.redhat.com (ovpn-115-147.rdu2.redhat.com
[10.10.115.147])
by smtp.corp.redhat.com (Postfix) with ESMTPS id DD9586294D;
Thu, 15 Apr 2021 12:51:28 +0000 (UTC)
From: Aaron Conole <aconole@redhat.com>
To: Olivier Matz <olivier.matz@6wind.com>
Cc: Thomas Monjalon <thomas@monjalon.net>, Wenwu Ma <wenwux.ma@intel.com>,
andrew.rybchenko@oktetlabs.ru, stable@dpdk.org, dev@dpdk.org,
zhihongx.peng@intel.com
References: <20210331210557.4919-1-wenwux.ma@intel.com>
<20210413200513.330399-1-wenwux.ma@intel.com>
<2483269.apo0RDFAAg@thomas> <20210415064521.GE1650@platinum>
Date: Thu, 15 Apr 2021 08:51:27 -0400
In-Reply-To: <20210415064521.GE1650@platinum> (Olivier Matz's message of "Thu,
15 Apr 2021 08:45:21 +0200")
Message-ID: <f7tk0p3aey8.fsf@dhcp-25.97.bos.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
Authentication-Results: relay.mimecast.com;
auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=aconole@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain
Subject: Re: [dpdk-dev] [dpdk-stable] [v2] test/mempool: fix heap buffer
overflow
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
Olivier Matz <olivier.matz@6wind.com> writes:
> 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.
Is it possible to have rte_mempool_get_priv() detect that the private
area isn't valid and return a ref to a const static member for this that
will have the correct mbuf_priv_size? There isn't really documentation
that I can find that describes this corner case with the mempool private
data section. Actually, it doesn't really say what happens if private
data size is 0, so maybe a documentation update should go with this test
case fix, too?
> 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