[PATCH net] qede: validate non LSO skb length

Although it is unlikely that stack could transmit a non LSO
skb with length > MTU, however in some cases or environment such
occurrences actually resulted into firmware asserts due to packet
length being greater than the max supported by the device (~9700B).

This patch adds the safeguard for such odd cases to avoid firmware
asserts.

Signed-off-by: Manish Chopra <manishc@marvell.com>
Signed-off-by: Alok Prasad <redacted>
Signed-off-by: Prabhakar Kushwaha <redacted>
Signed-off-by: Ariel Elior <redacted>
---
 drivers/net/ethernet/qlogic/qede/qede_fp.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/ethernet/qlogic/qede/qede_fp.c b/drivers/net/ethernet/qlogic/qede/qede_fp.c
index e113fbd56e86..5ea9cb4311a1 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_fp.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_fp.c

@@ -1644,6 +1644,13 @@ netdev_tx_t qede_start_xmit(struct sk_buff *skb, struct net_device *ndev)
 			data_split = true;
 		}
 	} else {
+		if (unlikely(skb->len > ETH_TX_MAX_NON_LSO_PKT_LEN)) {
+			DP_ERR(edev, "Unexpected non LSO skb length = 0x%x\n", skb->len);
+			qede_free_failed_tx_pkt(txq, first_bd, 0, false);
+			qede_update_tx_producer(txq);
+			return NETDEV_TX_OK;
+		}
+
 		val |= ((skb->len & ETH_TX_DATA_1ST_BD_PKT_LEN_MASK) <<
 			 ETH_TX_DATA_1ST_BD_PKT_LEN_SHIFT);
 	}

-- 
2.27.0

On Wed, 24 Nov 2021 01:24:05 -0800 Manish Chopra wrote:

Although it is unlikely that stack could transmit a non LSO
skb with length > MTU, however in some cases or environment such
occurrences actually resulted into firmware asserts due to packet
length being greater than the max supported by the device (~9700B).

This patch adds the safeguard for such odd cases to avoid firmware
asserts.

Signed-off-by: Manish Chopra <manishc@marvell.com>
Signed-off-by: Alok Prasad <redacted>
Signed-off-by: Prabhakar Kushwaha <redacted>
Signed-off-by: Ariel Elior <redacted>

Please add an appropriate Fixes tag and repost.

-----Original Message-----
From: Jakub Kicinski <kuba@kernel.org>
Sent: Thursday, November 25, 2021 5:08 AM
To: Manish Chopra <manishc@marvell.com>
Cc: netdev@vger.kernel.org; Ariel Elior <redacted>; Alok Prasad
[off-list ref]; Prabhakar Kushwaha [off-list ref]
Subject: [EXT] Re: [PATCH net] qede: validate non LSO skb length

External Email

----------------------------------------------------------------------
On Wed, 24 Nov 2021 01:24:05 -0800 Manish Chopra wrote:

quoted

Although it is unlikely that stack could transmit a non LSO skb with
length > MTU, however in some cases or environment such occurrences
actually resulted into firmware asserts due to packet length being
greater than the max supported by the device (~9700B).

This patch adds the safeguard for such odd cases to avoid firmware
asserts.

Signed-off-by: Manish Chopra <manishc@marvell.com>
Signed-off-by: Alok Prasad <redacted>
Signed-off-by: Prabhakar Kushwaha <redacted>
Signed-off-by: Ariel Elior <redacted>

Please add an appropriate Fixes tag and repost.

Hello Jakub,

I don't really know which commit has introduced this exactly. It was probably day1 (when this driver was submitted) behavior,
just that this issue was discovered recently by some customer environment.
Let me know if you want me to put one of those initial driver commit tag here and repost ? 

Thanks,
Manish  

On Thu, 2 Dec 2021 21:19:26 +0000 Manish Chopra wrote:

quoted

On Wed, 24 Nov 2021 01:24:05 -0800 Manish Chopra wrote:  

quoted

Although it is unlikely that stack could transmit a non LSO skb with
length > MTU, however in some cases or environment such occurrences
actually resulted into firmware asserts due to packet length being
greater than the max supported by the device (~9700B).

This patch adds the safeguard for such odd cases to avoid firmware
asserts.

Signed-off-by: Manish Chopra <manishc@marvell.com>
Signed-off-by: Alok Prasad <redacted>
Signed-off-by: Prabhakar Kushwaha <redacted>
Signed-off-by: Ariel Elior <redacted>  

Please add an appropriate Fixes tag and repost.  

Hello Jakub,

I don't really know which commit has introduced this exactly. It was
probably day1 (when this driver was submitted) behavior, just that
this issue was discovered recently by some customer environment. Let
me know if you want me to put one of those initial driver commit tag
here and repost ? 

Yes, that'd be best. This way any sort of automation for tracking which
fixes need to be backported will have clear signal that this fix
applies to all the kernels.