[PATCH v1] net/memif: fix segfault with Tx burst larger than 255

[PATCH v1] net/memif: fix segfault with Tx burst larger than 255

[Joyce Kong]

There will be a segfault when tx burst size is larger than
256. This is because eth_memif_tx uses an index i which is
uint8_t to count transmitted nb_pkts. Extend i to uint16_t,
the same size as nb_pkts.

Fixes: b5613c8f9d0a ("net/memif: add a Tx fast path")
Cc: stable@dpdk.org

Reported-by: Liangxing Wang <liangxing.wang@arm.com>
Signed-off-by: Joyce Kong <joyce.kong@arm.com>
Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
---
 drivers/net/memif/rte_eth_memif.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/memif/rte_eth_memif.c b/drivers/net/memif/rte_eth_memif.c
index 7cc8c0da91..6f45a00172 100644
--- a/drivers/net/memif/rte_eth_memif.c
+++ b/drivers/net/memif/rte_eth_memif.c
@@ -684,7 +684,7 @@ eth_memif_tx(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
 		n_free = __atomic_load_n(&ring->head, __ATOMIC_ACQUIRE) - slot;
 	}
 
-	uint8_t i;
+	uint16_t i;
 	struct rte_mbuf **buf_tmp = bufs;
 	mbuf_head = *buf_tmp++;
 	struct rte_mempool *mp = mbuf_head->pool;
-- 
2.25.1

Re: [PATCH v1] net/memif: fix segfault with Tx burst larger than 255

[Stephen Hemminger]

On Tue,  5 Dec 2023 04:05:24 +0000
Joyce Kong <joyce.kong@arm.com> wrote:

> There will be a segfault when tx burst size is larger than
> 256. This is because eth_memif_tx uses an index i which is
> uint8_t to count transmitted nb_pkts. Extend i to uint16_t,
> the same size as nb_pkts.
> 
> Fixes: b5613c8f9d0a ("net/memif: add a Tx fast path")
> Cc: stable@dpdk.org
> 
> Reported-by: Liangxing Wang <liangxing.wang@arm.com>
> Signed-off-by: Joyce Kong <joyce.kong@arm.com>
> Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> ---

I wonder if other drivers have same bug?

Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>

RE: [PATCH v1] net/memif: fix segfault with Tx burst larger than 255

[Joyce Kong]

> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Wednesday, December 6, 2023 2:34 AM
> To: Joyce Kong <Joyce.Kong@arm.com>
> Cc: Jakub Grajciar <jgrajcia@cisco.com>; Morten Brørup
> <mb@smartsharesystems.com>; Ruifeng Wang <Ruifeng.Wang@arm.com>;
> dev@dpdk.org; nd <nd@arm.com>; stable@dpdk.org; Liangxing Wang
> <Liangxing.Wang@arm.com>
> Subject: Re: [PATCH v1] net/memif: fix segfault with Tx burst larger than 255
> 
> On Tue,  5 Dec 2023 04:05:24 +0000
> Joyce Kong <joyce.kong@arm.com> wrote:
> 
> > There will be a segfault when tx burst size is larger than 256. This
> > is because eth_memif_tx uses an index i which is uint8_t to count
> > transmitted nb_pkts. Extend i to uint16_t, the same size as nb_pkts.
> >
> > Fixes: b5613c8f9d0a ("net/memif: add a Tx fast path")
> > Cc: stable@dpdk.org
> >
> > Reported-by: Liangxing Wang <liangxing.wang@arm.com>
> > Signed-off-by: Joyce Kong <joyce.kong@arm.com>
> > Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
> > ---
> 
> I wonder if other drivers have same bug?

I don't think this is a common bug.
This is a special case as the bug is introduced for whether choosing the memif Tx fast path. 

> 
> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>

Re: [PATCH v1] net/memif: fix segfault with Tx burst larger than 255

[Ferruh Yigit]

On 12/5/2023 6:33 PM, Stephen Hemminger wrote:
> On Tue,  5 Dec 2023 04:05:24 +0000
> Joyce Kong <joyce.kong@arm.com> wrote:
> 
>> There will be a segfault when tx burst size is larger than
>> 256. This is because eth_memif_tx uses an index i which is
>> uint8_t to count transmitted nb_pkts. Extend i to uint16_t,
>> the same size as nb_pkts.
>>
>> Fixes: b5613c8f9d0a ("net/memif: add a Tx fast path")
>> Cc: stable@dpdk.org
>>
>> Reported-by: Liangxing Wang <liangxing.wang@arm.com>
>> Signed-off-by: Joyce Kong <joyce.kong@arm.com>
>> Reviewed-by: Ruifeng Wang <ruifeng.wang@arm.com>
>> ---
> 
> I wonder if other drivers have same bug?
> 
> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
>

Acked-by: Ferruh Yigit <ferruh.yigit@amd.com>


Applied to dpdk-next-net/main, thanks.