From: Mohammad Shuab Siddique <mohammad-shuab.siddique@broadcom.com>
To: dev@dpdk.org
Cc: kishore.padmanabha@broadcom.com,
Joseph Wong <joseph.wong@broadcom.com>,
stable@dpdk.org,
Mohammad Shuab Siddique <mohammad-shuab.siddique@broadcom.com>
Subject: [PATCH 2/5] net/bnxt: fix bounds on firmware-reported resource counts
Date: Thu, 17 Sep 2026 21:27:23 -0600 [thread overview]
Message-ID: <20260918032726.763384-3-Mohammad-Shuab.Siddique@broadcom.com> (raw)
In-Reply-To: <20260918032726.763384-1-Mohammad-Shuab.Siddique@broadcom.com>
From: Joseph Wong <joseph.wong@broadcom.com>
When parsing max_ring_grps and max_l2_ctx values from firmware, clamp
values if they exceed a 16-bit value. max_hw_ring_grps is received as
32-bit in __bnxt_hwrm_func_qcaps() (the func_qcaps response) but cast
to 16-bit when used; add the clamp there and, as defense-in-depth,
also in bnxt_hwrm_func_resc_qcaps() in case that response's field ever
widens. max_l2_ctx is 16-bit in both responses, but its post-read
addition with max_rx_em_flows can overflow a 16-bit sum; widen the
addition to 32-bit and clamp the result.
Fixes: 2691827e82c ("net/bnxt: add HWRM VNIC alloc")
Fixes: 80bf6811fa0 ("net/bnxt: fix L2 context calculation for Thor")
Cc: stable@dpdk.org
Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
Signed-off-by: Mohammad Shuab Siddique <mohammad-shuab.siddique@broadcom.com>
---
drivers/net/bnxt/bnxt.h | 3 +++
drivers/net/bnxt/bnxt_hwrm.c | 16 ++++++++++++----
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bnxt/bnxt.h b/drivers/net/bnxt/bnxt.h
index 336de75da0..69455af31f 100644
--- a/drivers/net/bnxt/bnxt.h
+++ b/drivers/net/bnxt/bnxt.h
@@ -863,6 +863,9 @@ struct bnxt {
#define BNXT_P7_MAX_NQ_RING_CNT 512
#define BNXT_P7_CQ_MAX_L2_ENT 8192
+#define BNXT_MAX_RING_GRPS 65535U
+#define BNXT_MAX_L2_CTX 65535U
+
uint32_t flags2;
#define BNXT_FLAGS2_PTP_TIMESYNC_ENABLED BIT(0)
#define BNXT_FLAGS2_PTP_ALARM_SCHEDULED BIT(1)
diff --git a/drivers/net/bnxt/bnxt_hwrm.c b/drivers/net/bnxt/bnxt_hwrm.c
index aa8152eaa0..765aa7c452 100644
--- a/drivers/net/bnxt/bnxt_hwrm.c
+++ b/drivers/net/bnxt/bnxt_hwrm.c
@@ -1125,6 +1125,8 @@ static int __bnxt_hwrm_func_qcaps(struct bnxt *bp)
HWRM_CHECK_RESULT();
bp->max_ring_grps = rte_le_to_cpu_32(resp->max_hw_ring_grps);
+ if (bp->max_ring_grps > BNXT_MAX_RING_GRPS)
+ bp->max_ring_grps = BNXT_MAX_RING_GRPS;
flags = rte_le_to_cpu_32(resp->flags);
flags_ext2 = rte_le_to_cpu_32(resp->flags_ext2);
flags_ext3 = rte_le_to_cpu_32(resp->flags_ext3);
@@ -1155,8 +1157,10 @@ static int __bnxt_hwrm_func_qcaps(struct bnxt *bp)
bp->first_vf_id = rte_le_to_cpu_16(resp->first_vf_id);
bp->max_rx_em_flows = rte_le_to_cpu_16(resp->max_rx_em_flows);
bp->max_l2_ctx = rte_le_to_cpu_16(resp->max_l2_ctxs);
- if (!BNXT_CHIP_P5_P7(bp) && !bp->pdev->max_vfs)
- bp->max_l2_ctx += bp->max_rx_em_flows;
+ if (!BNXT_CHIP_P5_P7(bp) && !bp->pdev->max_vfs) {
+ uint32_t l2_ctx = bp->max_l2_ctx + bp->max_rx_em_flows;
+ bp->max_l2_ctx = (uint16_t)RTE_MIN(l2_ctx, (uint32_t)BNXT_MAX_L2_CTX);
+ }
if (bp->vnic_cap_flags & BNXT_VNIC_CAP_COS_CLASSIFY)
bp->max_vnics = rte_le_to_cpu_16(BNXT_MAX_VNICS_COS_CLASSIFY);
else
@@ -1556,12 +1560,16 @@ int bnxt_hwrm_func_resc_qcaps(struct bnxt *bp)
bp->max_tx_rings = rte_le_to_cpu_16(resp->max_tx_rings);
bp->max_rx_rings = rte_le_to_cpu_16(resp->max_rx_rings);
bp->max_ring_grps = rte_le_to_cpu_32(resp->max_hw_ring_grps);
+ if (bp->max_ring_grps > BNXT_MAX_RING_GRPS)
+ bp->max_ring_grps = BNXT_MAX_RING_GRPS;
/* func_resource_qcaps does not return max_rx_em_flows.
* So use the value provided by func_qcaps.
*/
bp->max_l2_ctx = rte_le_to_cpu_16(resp->max_l2_ctxs);
- if (!BNXT_CHIP_P5_P7(bp) && !bp->pdev->max_vfs)
- bp->max_l2_ctx += bp->max_rx_em_flows;
+ if (!BNXT_CHIP_P5_P7(bp) && !bp->pdev->max_vfs) {
+ uint32_t l2_ctx = bp->max_l2_ctx + bp->max_rx_em_flows;
+ bp->max_l2_ctx = (uint16_t)RTE_MIN(l2_ctx, (uint32_t)BNXT_MAX_L2_CTX);
+ }
if (bp->vnic_cap_flags & BNXT_VNIC_CAP_COS_CLASSIFY)
bp->max_vnics = rte_le_to_cpu_16(BNXT_MAX_VNICS_COS_CLASSIFY);
else
--
2.47.3
next prev parent reply other threads:[~2026-09-18 3:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 3:27 [PATCH 0/5] net/bnxt: fix VF and firmware-facing bounds/leak issues Mohammad Shuab Siddique
2026-09-18 3:27 ` [PATCH 1/5] net/bnxt: add VF ID boundary check before usage Mohammad Shuab Siddique
2026-09-18 3:27 ` Mohammad Shuab Siddique [this message]
2026-09-18 3:27 ` [PATCH 3/5] net/bnxt: fix use-after-free in VNIC filter cleanup Mohammad Shuab Siddique
2026-09-18 3:27 ` [PATCH 4/5] net/bnxt: fix memory leak in VF VNIC query error path Mohammad Shuab Siddique
2026-09-18 3:27 ` [PATCH 5/5] net/bnxt: fix VF info alloc error path memory leak Mohammad Shuab Siddique
2026-09-21 2:19 ` [PATCH v2 0/5] net/bnxt: fix VF and firmware-facing bounds/leak issues Mohammad Shuab Siddique
2026-09-21 2:19 ` [PATCH v2 1/5] net/bnxt: add VF ID boundary check before usage Mohammad Shuab Siddique
2026-09-21 2:19 ` [PATCH v2 2/5] net/bnxt: fix bounds on firmware-reported resource counts Mohammad Shuab Siddique
2026-09-21 15:47 ` Stephen Hemminger
2026-09-21 2:20 ` [PATCH v2 3/5] net/bnxt: fix use-after-free in VNIC filter cleanup Mohammad Shuab Siddique
2026-09-21 15:48 ` Stephen Hemminger
2026-09-21 2:20 ` [PATCH v2 4/5] net/bnxt: fix memory leak in VF VNIC query error path Mohammad Shuab Siddique
2026-09-21 2:20 ` [PATCH v2 5/5] net/bnxt: fix VF info alloc error path memory leak Mohammad Shuab Siddique
2026-09-29 0:24 ` [PATCH v3 0/5] net/bnxt: fix VF and firmware-facing bounds/leak issues Mohammad Shuab Siddique
2026-09-29 0:24 ` [PATCH v3 1/5] net/bnxt: add VF ID boundary check before usage Mohammad Shuab Siddique
2026-09-29 0:24 ` [PATCH v3 2/5] net/bnxt: fix bounds on firmware-reported resource counts Mohammad Shuab Siddique
2026-09-29 0:24 ` [PATCH v3 3/5] net/bnxt: fix VNIC filter list walk stopping early Mohammad Shuab Siddique
2026-09-29 0:24 ` [PATCH v3 4/5] net/bnxt: fix memory leak in VF VNIC query error path Mohammad Shuab Siddique
2026-09-29 0:24 ` [PATCH v3 5/5] net/bnxt: fix VF info alloc error path memory leak Mohammad Shuab Siddique
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=20260918032726.763384-3-Mohammad-Shuab.Siddique@broadcom.com \
--to=mohammad-shuab.siddique@broadcom.com \
--cc=dev@dpdk.org \
--cc=joseph.wong@broadcom.com \
--cc=kishore.padmanabha@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