All of lore.kernel.org
 help / color / mirror / Atom feed
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
Subject: Re: [dpdk-dev] [dpdk-stable] [v2] test/mempool: fix heap buffer overflow
Date: Thu, 15 Apr 2021 08:51:27 -0400	[thread overview]
Message-ID: <f7tk0p3aey8.fsf@dhcp-25.97.bos.redhat.com> (raw)
In-Reply-To: <20210415064521.GE1650@platinum> (Olivier Matz's message of "Thu,  15 Apr 2021 08:45:21 +0200")

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


  reply	other threads:[~2021-04-15 12:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-31 21:05 [dpdk-dev] [PATCH] test/mempool: Fix illegal pointer access in mempool test Wenwu Ma
2021-04-13 20:05 ` [dpdk-dev] [v2] test/mempool: fix heap buffer overflow Wenwu Ma
2021-04-13 11:52   ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
2021-04-15  6:45     ` Olivier Matz
2021-04-15 12:51       ` Aaron Conole [this message]
2021-04-16  7:20         ` Olivier Matz
2021-04-27 13:56   ` [dpdk-dev] [PATCH v3 1/2] " Olivier Matz
2021-04-27 13:56     ` [dpdk-dev] [PATCH v3 2/2] mbuf: better document usage of packet pool initializers Olivier Matz
2021-04-27 14:22       ` Aaron Conole
2021-05-04 18:07     ` [dpdk-dev] [dpdk-stable] [PATCH v3 1/2] test/mempool: fix heap buffer overflow Thomas Monjalon
2021-04-15  2:04 ` [dpdk-dev] [PATCH] test/mempool: Fix illegal pointer access in mempool test Peng, ZhihongX

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f7tk0p3aey8.fsf@dhcp-25.97.bos.redhat.com \
    --to=aconole@redhat.com \
    --cc=andrew.rybchenko@oktetlabs.ru \
    --cc=dev@dpdk.org \
    --cc=olivier.matz@6wind.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    --cc=wenwux.ma@intel.com \
    --cc=zhihongx.peng@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.