patch 'net/txgbe: validate lane number before use' has been queued to stable release 25.11.3

Kevin Traynor ktraynor at redhat.com
Thu Jul 30 11:16:18 CEST 2026


Hi,

FYI, your patch has been queued to stable release 25.11.3

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 08/04/26. So please
shout if anyone has objections.

Also note that after the patch there's a diff of the upstream commit vs the
patch applied to the branch. This will indicate if there was any rebasing
needed to apply to the stable branch. If there were code changes for rebasing
(ie: not only metadata diffs), please double check that the rebase was
correctly done.

Queued patches are on a temporary branch at:
https://github.com/kevintraynor/dpdk-stable

This queued commit can be viewed at:
https://github.com/kevintraynor/dpdk-stable/commit/3e5cd79945d54297d36721581fd30f270b14e921

Thanks.

Kevin

---
>From 3e5cd79945d54297d36721581fd30f270b14e921 Mon Sep 17 00:00:00 2001
From: Zaiyu Wang <zaiyuwang at trustnetic.com>
Date: Mon, 6 Jul 2026 18:47:19 +0800
Subject: [PATCH] net/txgbe: validate lane number before use

[ upstream commit 51f41cc3f1830c008f669263ac17ed30960bdb39 ]

Coverity reports multiple issues (INTEGER_OVERFLOW and BAD_SHIFT)
in the e56 backplane code. The root cause is that 'lane_num' is
initialized to 0 and only set in the switch statement based on
the link speed. The default case simply logs and breaks, leaving
lane_num as 0 for unsupported speeds.

This leads to unsigned underflow when evaluating 'lane_num - 1'
in GENMASK(lane_num - 1, 0), and undefined behavior when the
resulting mask is used in shift operations.

Fix by returning -EINVAL immediately in the default case of
txgbe_e56_cl72_training(), preventing any invalid speed from
proceeding further. Also add error handling at the call site
txgbe_handle_e56_bkp_an73_flow() to check the return value and
propagate the error.

For txgbe_e56_rxs_osc_init_for_temp_track_range(), no additional
check is added because:
1. It is called from txgbe_e56_cl72_training() after lane_num
   has been validated to one of the legal values (1, 2, 4, or 8).
2. The other caller, txgbe_e56_set_phy_link_mode(), passes a
   fixed speed of 10 (lane_num = 1), which is also valid.

Coverity issue: 504598, 504602, 504613
Fixes: 234ce0d1fa9d ("net/txgbe: fix link stability for Amber-Lite backplane mode")

Signed-off-by: Zaiyu Wang <zaiyuwang at trustnetic.com>
---
 drivers/net/txgbe/base/txgbe_e56_bp.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/txgbe/base/txgbe_e56_bp.c b/drivers/net/txgbe/base/txgbe_e56_bp.c
index f8b39a0c7e..d376d918df 100644
--- a/drivers/net/txgbe/base/txgbe_e56_bp.c
+++ b/drivers/net/txgbe/base/txgbe_e56_bp.c
@@ -2433,5 +2433,5 @@ static int txgbe_e56_cl72_training(struct txgbe_hw *hw)
 	default:
 		BP_LOG("%s %d :Invalid speed\n", __func__, __LINE__);
-		break;
+		return -EINVAL;
 	}
 
@@ -2584,4 +2584,8 @@ int txgbe_handle_e56_bkp_an73_flow(struct txgbe_hw *hw)
 
 	status = txgbe_e56_cl72_training(hw);
+	if (status) {
+		BP_LOG("CL72 training failed, status = %d\n", status);
+		return status;
+	}
 
 	rdata = rd32_ephy(hw, E56PHY_RXS_IDLE_DETECT_1_ADDR);
-- 
2.55.0

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2026-07-30 10:16:02.640962180 +0100
+++ 0039-net-txgbe-validate-lane-number-before-use.patch	2026-07-30 10:16:01.480757829 +0100
@@ -1 +1 @@
-From 51f41cc3f1830c008f669263ac17ed30960bdb39 Mon Sep 17 00:00:00 2001
+From 3e5cd79945d54297d36721581fd30f270b14e921 Mon Sep 17 00:00:00 2001
@@ -5,0 +6,2 @@
+[ upstream commit 51f41cc3f1830c008f669263ac17ed30960bdb39 ]
+
@@ -31 +32,0 @@
-Cc: stable at dpdk.org



More information about the stable mailing list