On Sun, 20 Sep 2026 20:19:59 -0600 Mohammad Shuab Siddique <[email protected]> wrote:
> From: Joseph Wong <[email protected]> > > 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: [email protected] > > Signed-off-by: Joseph Wong <[email protected]> > Signed-off-by: Mohammad Shuab Siddique <[email protected]> > --- 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.
