Re[2]: [PATCH 1/1] net/bnxt: fix string bounds checks and format specifiers

[Денис Люлин]

> > diff --git a/drivers/net/bnxt/bnxt_ethdev.c
> > b/drivers/net/bnxt/bnxt_ethdev.c
> > index b677f9491d..bb02a2579b 100644
> > --- a/drivers/net/bnxt/bnxt_ethdev.c
> > +++ b/drivers/net/bnxt/bnxt_ethdev.c
> > @@ -652,8 +652,9 @@ static int bnxt_init_fc_ctx_mem(struct bnxt *bp)
> >
> > max_fc = bp->flow_stat->max_fc;
> >
> > - sprintf(type, "bnxt_rx_fc_in_" PCI_PRI_FMT, pdev->addr.domain,
> > - pdev->addr.bus, pdev->addr.devid, pdev->addr.function);
> > + snprintf(type, RTE_MEMZONE_NAMESIZE, "bnxt_rx_fc_in_" PCI_PRI_FMT,
> > + pdev->addr.domain, pdev->addr.bus,
> > + pdev->addr.devid, pdev->addr.function);
> > /* 4 bytes for each counter-id */

>Rather than silently truncating, it should return an error.

As far as I understand, these strings are used as diagnostic information when tracing is enabled. Is the truncation of a debug string so critical that we should interrupt device initialization by returning an error? For example, Linux kernel truncates worker thread names if the strings are too long

пятница, 17 апреля 2026г., 20:04 +03:00 от Stephen Hemminger stephen at networkplumber.org :

> 
> On Fri, 17 Apr 2026 12:43:07 -0400
> Kishore Padmanabha <kishore.padmanabha at broadcom.com (
> /compose?To=kishore.padmanabha at broadcom.com )> wrote:
> 
> > > diff --git a/drivers/net/bnxt/bnxt_ethdev.c
> > > b/drivers/net/bnxt/bnxt_ethdev.c
> > > index b677f9491d..bb02a2579b 100644
> > > --- a/drivers/net/bnxt/bnxt_ethdev.c
> > > +++ b/drivers/net/bnxt/bnxt_ethdev.c
> > > @@ -652,8 +652,9 @@ static int bnxt_init_fc_ctx_mem(struct bnxt *bp)
> > >
> > > max_fc = bp->flow_stat->max_fc;
> > >
> > > - sprintf(type, "bnxt_rx_fc_in_" PCI_PRI_FMT, pdev->addr.domain,
> > > - pdev->addr.bus, pdev->addr.devid, pdev->addr.function);
> > > + snprintf(type, RTE_MEMZONE_NAMESIZE, "bnxt_rx_fc_in_" PCI_PRI_FMT,
> > > + pdev->addr.domain, pdev->addr.bus,
> > > + pdev->addr.devid, pdev->addr.function);
> > > /* 4 bytes for each counter-id */
> 
> Rather than silently truncating, it should return an error.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/stable/attachments/20260422/70217d0f/attachment.htm>