DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] net/iavf: fix overflow in maximum packet length config
@ 2021-08-05 11:35 Tudor Cornea
  2021-08-30  1:04 ` Zhang, Qi Z
  0 siblings, 1 reply; 2+ messages in thread
From: Tudor Cornea @ 2021-08-05 11:35 UTC (permalink / raw)
  To: jingjing.wu, beilei.xing; +Cc: qi.z.zhang, dev, Tudor Cornea

The len variable, used in the computation of max_pkt_len could
overflow, if used to store the result of the following computation:

rxq->rx_buf_len * IAVF_MAX_CHAINED_RX_BUFFERS

Since, we could define the mbuf size to have a large value (i.e 13312),
and IAVF_MAX_CHAINED_RX_BUFFERS is defined as 5, the computation mentioned
above could potentially result in a value which might be bigger than MAX_USHORT.

The result will be that Jumbo Frames will not work properly

A similar fix was submitted for the ice driver

Signed-off-by: Tudor Cornea <tudor.cornea@gmail.com>
---
 drivers/net/iavf/iavf_ethdev.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/iavf/iavf_ethdev.c b/drivers/net/iavf/iavf_ethdev.c
index 574cfe0..dc5cbc2 100644
--- a/drivers/net/iavf/iavf_ethdev.c
+++ b/drivers/net/iavf/iavf_ethdev.c
@@ -574,13 +574,14 @@ iavf_init_rxq(struct rte_eth_dev *dev, struct iavf_rx_queue *rxq)
 {
 	struct iavf_hw *hw = IAVF_DEV_PRIVATE_TO_HW(dev->data->dev_private);
 	struct rte_eth_dev_data *dev_data = dev->data;
-	uint16_t buf_size, max_pkt_len, len;
+	uint16_t buf_size, max_pkt_len;
 
 	buf_size = rte_pktmbuf_data_room_size(rxq->mp) - RTE_PKTMBUF_HEADROOM;
 
 	/* Calculate the maximum packet length allowed */
-	len = rxq->rx_buf_len * IAVF_MAX_CHAINED_RX_BUFFERS;
-	max_pkt_len = RTE_MIN(len, dev->data->dev_conf.rxmode.max_rx_pkt_len);
+	max_pkt_len = RTE_MIN((uint32_t)
+			rxq->rx_buf_len * IAVF_MAX_CHAINED_RX_BUFFERS,
+			dev->data->dev_conf.rxmode.max_rx_pkt_len);
 
 	/* Check if the jumbo frame and maximum packet length are set
 	 * correctly.
-- 
2.7.4


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [dpdk-dev] [PATCH] net/iavf: fix overflow in maximum packet length config
  2021-08-05 11:35 [dpdk-dev] [PATCH] net/iavf: fix overflow in maximum packet length config Tudor Cornea
@ 2021-08-30  1:04 ` Zhang, Qi Z
  0 siblings, 0 replies; 2+ messages in thread
From: Zhang, Qi Z @ 2021-08-30  1:04 UTC (permalink / raw)
  To: Tudor Cornea, Wu, Jingjing, Xing, Beilei; +Cc: dev



> -----Original Message-----
> From: Tudor Cornea <tudor.cornea@gmail.com>
> Sent: Thursday, August 5, 2021 7:35 PM
> To: Wu, Jingjing <jingjing.wu@intel.com>; Xing, Beilei <beilei.xing@intel.com>
> Cc: Zhang, Qi Z <qi.z.zhang@intel.com>; dev@dpdk.org; Tudor Cornea
> <tudor.cornea@gmail.com>
> Subject: [PATCH] net/iavf: fix overflow in maximum packet length config
> 
> The len variable, used in the computation of max_pkt_len could overflow, if
> used to store the result of the following computation:
> 
> rxq->rx_buf_len * IAVF_MAX_CHAINED_RX_BUFFERS
> 
> Since, we could define the mbuf size to have a large value (i.e 13312), and
> IAVF_MAX_CHAINED_RX_BUFFERS is defined as 5, the computation mentioned
> above could potentially result in a value which might be bigger than
> MAX_USHORT.
> 
> The result will be that Jumbo Frames will not work properly
> 
> A similar fix was submitted for the ice driver

Fixes: 69dd4c3d0898 ("net/avf: enable queue and device")
Cc: stable@dpdk.org

> 
> Signed-off-by: Tudor Cornea <tudor.cornea@gmail.com>

Acked-by: Qi Zhang <qi.z.zhang@intel.com>

Applied to dpdk-next-net-intel.

Thanks
Qi


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-08-30  1:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-05 11:35 [dpdk-dev] [PATCH] net/iavf: fix overflow in maximum packet length config Tudor Cornea
2021-08-30  1:04 ` Zhang, Qi Z

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).