From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Kees Cook <keescook@chromium.org>, Justin Stitt <justinstitt@google.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>, <netdev@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-hardening@vger.kernel.org>
Subject: Re: [PATCH] net: dsa: lan9303: replace deprecated strncpy with memcpy
Date: Thu, 5 Oct 2023 16:53:14 +0200 [thread overview]
Message-ID: <984bcd4d-627e-7d26-2a50-73607ea0eecd@intel.com> (raw)
In-Reply-To: <202310042201.7B14CA59@keescook>
From: Kees Cook <keescook@chromium.org>
Date: Wed, 4 Oct 2023 22:02:00 -0700
> On Wed, Oct 04, 2023 at 08:07:55PM -0700, Kees Cook wrote:
>> On Thu, Oct 05, 2023 at 12:30:18AM +0000, Justin Stitt wrote:
>>> `strncpy` is deprecated for use on NUL-terminated destination strings
>>> [1] and as such we should prefer more robust and less ambiguous
>>> interfaces.
>>>
>>> Let's opt for memcpy as we are copying strings into slices of length
>>> `ETH_GSTRING_LEN` within the `data` buffer. Other similar get_strings()
>>> implementations [2] [3] use memcpy().
>>>
>>> Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
>>> Link: https://elixir.bootlin.com/linux/v6.3/source/drivers/infiniband/ulp/opa_vnic/opa_vnic_ethtool.c#L167 [2]
>>> Link: https://elixir.bootlin.com/linux/v6.3/source/drivers/infiniband/ulp/ipoib/ipoib_ethtool.c#L137 [3]
>>> Link: https://github.com/KSPP/linux/issues/90
>>> Cc: linux-hardening@vger.kernel.org
>>> Signed-off-by: Justin Stitt <justinstitt@google.com>
>>> ---
>>> Note: build-tested only.
>>> ---
>>> drivers/net/dsa/lan9303-core.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
>>> index ee67adeb2cdb..665d69384b62 100644
>>> --- a/drivers/net/dsa/lan9303-core.c
>>> +++ b/drivers/net/dsa/lan9303-core.c
>>> @@ -1013,8 +1013,8 @@ static void lan9303_get_strings(struct dsa_switch *ds, int port,
>>> return;
>>>
>>> for (u = 0; u < ARRAY_SIZE(lan9303_mib); u++) {
>>> - strncpy(data + u * ETH_GSTRING_LEN, lan9303_mib[u].name,
>>> - ETH_GSTRING_LEN);
>>> + memcpy(data + u * ETH_GSTRING_LEN, lan9303_mib[u].name,
>>> + ETH_GSTRING_LEN);
>>
>> This won't work because lan9303_mib entries aren't ETH_GSTRING_LEN-long
>> strings; they're string pointers:
>>
>> static const struct lan9303_mib_desc lan9303_mib[] = {
>> { .offset = LAN9303_MAC_RX_BRDCST_CNT_0, .name = "RxBroad", },
>>
>> So this really does need a strcpy-family function.
>>
>> And, I think the vnic_gstrings_stats and ipoib_gstrings_stats examples
>> are actually buggy -- they're copying junk into userspace...
>>
>> I am reminded of this patch, which correctly uses strscpy_pad():
>> https://lore.kernel.org/lkml/20230718-net-dsa-strncpy-v1-1-e84664747713@google.com/
>>
>> I think you want to do the same here, and use strscpy_pad(). And perhaps
>> send some fixes for the other memcpy() users?
>
> Meh, I think it's not worth fixing the memcpy() users of this. This
> buggy pattern is very common, it seems:
>
> $ git grep 'data.*ETH_GSTRING_LEN' | grep memcpy | wc -l
> 47
We have ethtool_sprintf() precisely for the sake of filling the Ethtool
statistics names.
BTW this weird pattern "let's make the array of our stats names of fixed
width (ETH_GSTRING_LEN), so that we could use memcpy() instead of
strcpy()" was pretty common some time ago, no idea why, as it wastes
memory for tons of \0 padding and provokes issues like the one you
noticed here.
>
Thanks,
Olek
next prev parent reply other threads:[~2023-10-05 14:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-05 0:30 [PATCH] net: dsa: lan9303: replace deprecated strncpy with memcpy Justin Stitt
2023-10-05 3:07 ` Kees Cook
2023-10-05 5:02 ` Kees Cook
2023-10-05 14:53 ` Alexander Lobakin [this message]
2023-10-05 18:58 ` Justin Stitt
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=984bcd4d-627e-7d26-2a50-73607ea0eecd@intel.com \
--to=aleksander.lobakin@intel.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=justinstitt@google.com \
--cc=keescook@chromium.org \
--cc=kuba@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.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;
as well as URLs for NNTP newsgroup(s).