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 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 ; 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 To: Olivier Matz Cc: Thomas Monjalon , Wenwu Ma , 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Olivier Matz 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