patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Mihai Brodschi <mihai.brodschi@broadcom.com>,
	Jakub Grajciar <jgrajcia@cisco.com>
Cc: dev@dpdk.org, stable@dpdk.org
Subject: Re: [PATCH v2] net/memif: fix buffer overflow in zero copy Rx
Date: Sun, 7 Jul 2024 03:12:51 +0100	[thread overview]
Message-ID: <a6d15ff1-812f-44ea-8328-631bf0f58fc2@amd.com> (raw)
In-Reply-To: <c3a72bcb-24b0-4c42-9a07-427eadce029a@broadcom.com>

On 6/28/2024 10:01 PM, Mihai Brodschi wrote:
> rte_pktmbuf_alloc_bulk is called by the zero-copy receiver to allocate
> new mbufs to be provided to the sender. The allocated mbuf pointers
> are stored in a ring, but the alloc function doesn't implement index
> wrap-around, so it writes past the end of the array. This results in
> memory corruption and duplicate mbufs being received.
> 

Hi Mihai,

I am not sure writing past the ring actually occurs.

As far as I can see is to keep the ring full as much as possible, when
initially 'head' and 'tail' are 0, it fills all ring.
Later tails moves and emptied space filled again. So head (in modulo) is
always just behind tail after refill. In next run, refill will only fill
the part tail moved, and this is calculated by 'n_slots'. As this is
only the size of the gap, starting from 'head' (with modulo) shouldn't
pass the ring length.

Do you observe this issue practically? If so can you please provide your
backtrace and numbers that is showing how to reproduce the issue?


> Allocate 2x the space for the mbuf ring, so that the alloc function
> has a contiguous array to write to, then copy the excess entries
> to the start of the array.
> 

Even issue is valid, I am not sure about solution to double to buffer
memory, but lets confirm the issue first before discussing the solution.

> Fixes: 43b815d88188 ("net/memif: support zero-copy slave")
> Cc: stable@dpdk.org
> Signed-off-by: Mihai Brodschi <mihai.brodschi@broadcom.com>
> ---
> v2:
>  - fix email formatting
> 
> ---
>  drivers/net/memif/rte_eth_memif.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/memif/rte_eth_memif.c b/drivers/net/memif/rte_eth_memif.c
> index 16da22b5c6..3491c53cf1 100644
> --- a/drivers/net/memif/rte_eth_memif.c
> +++ b/drivers/net/memif/rte_eth_memif.c
> @@ -600,6 +600,10 @@ eth_memif_rx_zc(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
>  	ret = rte_pktmbuf_alloc_bulk(mq->mempool, &mq->buffers[head & mask], n_slots);
>  	if (unlikely(ret < 0))
>  		goto no_free_mbufs;
> +	if (unlikely(n_slots > ring_size - (head & mask))) {
> +		rte_memcpy(mq->buffers, &mq->buffers[ring_size],
> +			(n_slots + (head & mask) - ring_size) * sizeof(struct rte_mbuf *));
> +	}
>  
>  	while (n_slots--) {
>  		s0 = head++ & mask;
> @@ -1245,8 +1249,12 @@ memif_init_queues(struct rte_eth_dev *dev)
>  		}
>  		mq->buffers = NULL;
>  		if (pmd->flags & ETH_MEMIF_FLAG_ZERO_COPY) {
> +			/*
> +			 * Allocate 2x ring_size to reserve a contiguous array for
> +			 * rte_pktmbuf_alloc_bulk (to store allocated mbufs).
> +			 */
>  			mq->buffers = rte_zmalloc("bufs", sizeof(struct rte_mbuf *) *
> -						  (1 << mq->log2_ring_size), 0);
> +						  (1 << (mq->log2_ring_size + 1)), 0);
>  			if (mq->buffers == NULL)
>  				return -ENOMEM;
>  		}


  parent reply	other threads:[~2024-07-07  2:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-28 21:01 Mihai Brodschi
2024-07-01  4:57 ` Patrick Robb
2024-07-07  2:12 ` Ferruh Yigit [this message]
2024-07-07  5:50   ` Mihai Brodschi
2024-07-07 14:05     ` Ferruh Yigit
2024-07-07 15:18       ` Mihai Brodschi
2024-07-07 18:46         ` Mihai Brodschi
2024-07-08  3:39           ` Mihai Brodschi
2024-07-08 11:45             ` Ferruh Yigit
2024-07-19  9:03               ` Ferruh Yigit
2024-08-31 13:38                 ` Mihai Brodschi
2024-07-07  5:31 Mihai Brodschi

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=a6d15ff1-812f-44ea-8328-631bf0f58fc2@amd.com \
    --to=ferruh.yigit@amd.com \
    --cc=dev@dpdk.org \
    --cc=jgrajcia@cisco.com \
    --cc=mihai.brodschi@broadcom.com \
    --cc=stable@dpdk.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).