From: Leon Romanovsky <leon@kernel.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Peter Kosyh <pkosyh@yandex.ru>, Tariq Toukan <tariqt@nvidia.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, lvc-project@linuxtesting.org
Subject: Re: [PATCH] mlx4: use snprintf() instead of sprintf() for safety
Date: Wed, 23 Nov 2022 08:40:57 +0200 [thread overview]
Message-ID: <Y33AeQzuXFjnr+t/@unreal> (raw)
In-Reply-To: <20221122121223.265d6d97@kernel.org>
On Tue, Nov 22, 2022 at 12:12:23PM -0800, Jakub Kicinski wrote:
> On Tue, 22 Nov 2022 16:48:15 +0200 Leon Romanovsky wrote:
> > On Tue, Nov 22, 2022 at 04:04:53PM +0300, Peter Kosyh wrote:
> > > Use snprintf() to avoid the potential buffer overflow. Although in the
> > > current code this is hardly possible, the safety is unclean.
> >
> > Let's fix the tools instead. The kernel code is correct.
>
> I'm guessing the code is correct because port can't be a high value?
Yes, port value is provided as input to mlx4_init_port_info() and it is
capped by MLX4_MAX_PORTS, which is 2.
> Otherwise, if I'm counting right, large enough port representation
> (e.g. 99999999) could overflow the string. If that's the case - how
> would they "fix the tool" to know the port is always a single digit?
I may admit that I don't know how hard or easy to implement it, but it
will be great if tool would be able to understand that dev->caps.num_ports
are not really dynamic values, but constant ones.
However, I don't mind if we merge it.
Thanks,
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
prev parent reply other threads:[~2022-11-23 6:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-22 13:04 [PATCH] mlx4: use snprintf() instead of sprintf() for safety Peter Kosyh
2022-11-22 14:48 ` Leon Romanovsky
2022-11-22 20:12 ` Jakub Kicinski
2022-11-23 4:43 ` Saeed Mahameed
2022-11-23 6:40 ` Leon Romanovsky [this message]
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=Y33AeQzuXFjnr+t/@unreal \
--to=leon@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pkosyh@yandex.ru \
--cc=tariqt@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.