From: Stephen Hemminger <stephen@networkplumber.org>
To: Mohammad Shuab Siddique <mohammad-shuab.siddique@broadcom.com>
Cc: dev@dpdk.org, kishore.padmanabha@broadcom.com,
Keegan Freyhof <keegan.freyhof@broadcom.com>,
Mohammad Shuab Siddique <shuab.siddique@broadcom.com>
Subject: Re: [PATCH v2 3/5] net/bnxt: harden sprintf bounds for device memory names
Date: Mon, 21 Sep 2026 08:49:57 -0700 [thread overview]
Message-ID: <20260921084957.3cb42f6f@phoenix.local> (raw)
In-Reply-To: <20260921022420.1034071-4-Mohammad-Shuab.Siddique@broadcom.com>
On Sun, 20 Sep 2026 20:24:18 -0600
Mohammad Shuab Siddique <mohammad-shuab.siddique@broadcom.com> wrote:
> From: Keegan Freyhof <keegan.freyhof@broadcom.com>
>
> sprintf() into fixed-size stack buffers such as
> char type[RTE_MEMZONE_NAMESIZE] does not bound the write to the
> buffer, so a long enough formatted string (e.g. from PCI address
> fields) overflows it.
>
> Add check_snprintf_rc(), a helper that logs and returns an error on a
> failed snprintf() call and logs (without failing) a truncated one.
> Convert sprintf() calls building a memzone/malloc name to snprintf()
> plus this check, and add the same check to the existing snprintf()
> calls building HWRM CFA pair_name request fields. Unlike a truncated
> memzone/malloc label, a truncated pair_name would be sent to firmware
> and could match the wrong pair or none at all, so
> bnxt_hwrm_cfa_pair_exists()/_alloc()/_free() additionally reject a
> truncated pair_name outright instead of proceeding.
>
> Three bugs introduced by this change and fixed here: in
> bnxt_hwrm_ver_get(), free bp->hwrm_short_cmd_req_addr (and null it)
> before checking the new snprintf's return, instead of after, so an
> early return on a snprintf failure doesn't leak the previous
> allocation; also clear BNXT_FLAG_SHORT_CMD on that same early return,
> since it may already have been set a few lines above and would
> otherwise claim short-command support with no buffer allocated. In
> bnxt_hwrm_cfa_pair_exists()/_alloc()/_free(), the new early-return
> paths exited without releasing bp->hwrm_lock (held since the
> preceding HWRM_PREP()), which would deadlock every later HWRM call;
> added the missing HWRM_UNLOCK() before each return.
>
> Signed-off-by: Keegan Freyhof <keegan.freyhof@broadcom.com>
> Signed-off-by: Mohammad Shuab Siddique <shuab.siddique@broadcom.com>
>
> ---
[PATCH v2 3/5] net/bnxt: harden sprintf bounds for device memory
names
Error: does not apply to main (see summary).
Warning: the rc < 0 branch of check_snprintf_rc() is unreachable.
snprintf() only fails on encoding errors, which cannot happen with
these formats. Every converted name except pair_name is an
rte_malloc()/rte_zmalloc_socket() type label. That label is
informational only, so truncation is harmless.
The only real overflow is a PCI domain above 0xffff with
"bnxt_hwrm_short_": 16 + 8 + 8 = 32 chars plus NUL into 32 bytes.
Plain snprintf() fixes that. Drop the helper and the early-return
paths, including the flag clearing and unlock handling added for
unreachable code.
For pair_name, rejecting truncation is reasonable. A single
"if (snprintf(...) >= sizeof(req.pair_name))" with HWRM_UNLOCK()
covers it.
Warning: the commit body carries review history ("Three bugs
introduced by this change and fixed here..."). Move it below ---.
Info: the flow xstat names can be written with snprintf() directly
into xstats_names[count].name, dropping buf and strlcpy(). "_%d_%d"
cannot exceed 32 bytes, so it needs no check.
Info: if the PCI domain overflow is the motivation, add Fixes: and
Cc: stable@dpdk.org.
next prev parent reply other threads:[~2026-09-21 15:54 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 flow, Rx and naming bounds issues Mohammad Shuab Siddique
2026-09-18 3:27 ` [PATCH 1/5] net/bnxt: fix stack exhaustion in flow stats Mohammad Shuab Siddique
2026-09-18 3:27 ` [PATCH 2/5] net/bnxt: fix bounds on TPA aggregation ID from completions Mohammad Shuab Siddique
2026-09-18 3:27 ` [PATCH 3/5] net/bnxt: harden sprintf bounds for device memory names Mohammad Shuab Siddique
2026-09-18 3:27 ` [PATCH 4/5] net/bnxt: fix bounds in MAC pool index and flow parsing Mohammad Shuab Siddique
2026-09-18 3:27 ` [PATCH 5/5] net/bnxt: fix TPA agg Rx descriptor and VNIC query bounds Mohammad Shuab Siddique
2026-09-21 2:24 ` [PATCH v2 0/5] net/bnxt: fix flow, Rx and naming bounds issues Mohammad Shuab Siddique
2026-09-21 2:24 ` [PATCH v2 1/5] net/bnxt: fix stack exhaustion in flow stats Mohammad Shuab Siddique
2026-09-21 2:24 ` [PATCH v2 2/5] net/bnxt: fix bounds on TPA aggregation ID from completions Mohammad Shuab Siddique
2026-09-21 2:24 ` [PATCH v2 3/5] net/bnxt: harden sprintf bounds for device memory names Mohammad Shuab Siddique
2026-09-21 15:49 ` Stephen Hemminger [this message]
2026-09-21 2:24 ` [PATCH v2 4/5] net/bnxt: fix bounds in MAC pool index and flow parsing Mohammad Shuab Siddique
2026-09-21 15:50 ` Stephen Hemminger
2026-09-21 2:24 ` [PATCH v2 5/5] net/bnxt: fix TPA agg Rx descriptor and VNIC query bounds Mohammad Shuab Siddique
2026-09-29 0:24 ` [PATCH v3 0/5] net/bnxt: fix flow, Rx and naming bounds issues Mohammad Shuab Siddique
2026-09-29 0:24 ` [PATCH v3 1/5] net/bnxt: fix stack exhaustion in flow stats Mohammad Shuab Siddique
2026-09-29 0:24 ` [PATCH v3 2/5] net/bnxt: validate TPA aggregation ID from completions Mohammad Shuab Siddique
2026-09-29 0:24 ` [PATCH v3 3/5] net/bnxt: harden sprintf bounds for device memory names Mohammad Shuab Siddique
2026-09-29 0:24 ` [PATCH v3 4/5] net/bnxt: fix bounds in MAC address pool index Mohammad Shuab Siddique
2026-09-29 0:24 ` [PATCH v3 5/5] net/bnxt: fix TPA agg Rx descriptor and VNIC query bounds 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=20260921084957.3cb42f6f@phoenix.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=keegan.freyhof@broadcom.com \
--cc=kishore.padmanabha@broadcom.com \
--cc=mohammad-shuab.siddique@broadcom.com \
--cc=shuab.siddique@broadcom.com \
/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