[PATCH v2 2/5] net/bnxt: fix bounds on firmware-reported resource counts

[Stephen Hemminger]

On Sun, 20 Sep 2026 20:19:59 -0600
Mohammad Shuab Siddique <mohammad-shuab.siddique at broadcom.com> wrote:

> From: Joseph Wong <joseph.wong at 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: 2691827e82c0 ("net/bnxt: add HWRM VNIC alloc")
> Fixes: 80bf6811fa0f ("net/bnxt: fix L2 context calculation for Thor")
> Cc: stable at dpdk.org
> 
> Signed-off-by: Joseph Wong <joseph.wong at broadcom.com>
> Signed-off-by: Mohammad Shuab Siddique <mohammad-shuab.siddique at broadcom.com>
> ---

Better  AI review flagged:



[PATCH v2 2/5] net/bnxt: fix bounds on firmware-reported resource
counts

Warning: in bnxt_hwrm_func_resc_qcaps(), resp->max_hw_ring_grps is
uint16_t in hwrm_func_resource_qcaps_output but is read with
rte_le_to_cpu_32(). On little endian the new clamp is dead code. On
big endian the 32-bit swap of a 16-bit field yields value << 16,
which the clamp turns into 65535. The fix is rte_le_to_cpu_16(); the
"in case the field ever widens" clamp should go.