From: Jakub Kicinski <kuba@kernel.org>
To: Jijie Shao <shaojijie@huawei.com>, Kees Cook <keescook@chromium.org>
Cc: Leon Romanovsky <leon@kernel.org>, <yisen.zhuang@huawei.com>,
<salil.mehta@huawei.com>, <davem@davemloft.net>,
<edumazet@google.com>, <pabeni@redhat.com>,
<shenjian15@huawei.com>, <wangjie125@huawei.com>,
<liuyonglong@huawei.com>, <chenhao418@huawei.com>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<stable@vger.kernel.org>
Subject: Re: [PATCH net] net: hns3: fix strscpy causing content truncation issue
Date: Thu, 10 Aug 2023 10:22:47 -0700 [thread overview]
Message-ID: <20230810102247.699ddc14@kernel.org> (raw)
In-Reply-To: <7c44c161-9c86-8c60-f031-6d77d6c28c20@huawei.com>
On Thu, 10 Aug 2023 15:45:50 +0800 Jijie Shao wrote:
> on 2023/8/9 15:03, Leon Romanovsky wrote:
> > On Wed, Aug 09, 2023 at 10:09:02AM +0800, Jijie Shao wrote:
> >> From: Hao Chen <chenhao418@huawei.com>
> >>
> >> hns3_dbg_fill_content()/hclge_dbg_fill_content() is aim to integrate some
> >> items to a string for content, and we add '\n' and '\0' in the last
> >> two bytes of content.
> >>
> >> strscpy() will add '\0' in the last byte of destination buffer(one of
> >> items), it result in finishing content print ahead of schedule and some
> >> dump content truncation.
> >>
> >> One Error log shows as below:
> >> cat mac_list/uc
> >> UC MAC_LIST:
> >>
> >> Expected:
> >> UC MAC_LIST:
> >> FUNC_ID MAC_ADDR STATE
> >> pf 00:2b:19:05:03:00 ACTIVE
> >>
> >> The destination buffer is length-bounded and not required to be
> >> NUL-terminated, so just change strscpy() to memcpy() to fix it.
> > I think that you should change to strtomem() and not use plain memcpy().
> >
> > Thanks
>
> Hi:
>
> We tried to replace memcpy with strtomem, but errors was reported during
> compilation:
> /kernel/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c: In
> function ‘hclge_dbg_fill_content.part.0’:
> /kernel/include/linux/compiler_types.h:397:38: error: call to
> ‘__compiletime_assert_519’ declared with attribute error: BUILD_BUG_ON
> failed: !__builtin_constant_p(_dest_len) || _dest_len == (size_t)-1
> 397 | _compiletime_assert(condition, msg, __compiletime_assert_,
> __COUNTER__)
> | ^
> /kernel/include/linux/compiler_types.h:378:4: note: in definition of
> macro ‘__compiletime_assert’
> 378 | prefix ## suffix(); \
> | ^~~~~~
> /kernel/include/linux/compiler_types.h:397:2: note: in expansion of
> macro ‘_compiletime_assert’
> 397 | _compiletime_assert(condition, msg, __compiletime_assert_,
> __COUNTER__)
> | ^~~~~~~~~~~~~~~~~~~
> /kernel/include/linux/build_bug.h:39:37: note: in expansion of macro
> ‘compiletime_assert’
> 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond),
> msg)
> | ^~~~~~~~~~~~~~~~~~
> /kernel/include/linux/build_bug.h:50:2: note: in expansion of macro
> ‘BUILD_BUG_ON_MSG’
> 50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> | ^~~~~~~~~~~~~~~~
> /kernel/include/linux/string.h:302:2: note: in expansion of macro
> ‘BUILD_BUG_ON’
> 302 | BUILD_BUG_ON(!__builtin_constant_p(_dest_len) || \
> | ^~~~~~~~~~~~
> /kernel/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c:115:4:
> note: in expansion of macro ‘strtomem’
> 115 | strtomem(pos, result[i]);
> | ^~~~~~~~
>
> In the strtomem macro, __builtin_object_size is used to calculate the
> _dest_len.
> We tried to print the _dest_len directly, and the result was -1.
> How can we solve this?
Let's add Kees in case he has a immediate recommendation on use of
strtomem() vs memcpy() for this case..
next prev parent reply other threads:[~2023-08-10 17:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-09 2:09 [PATCH net] net: hns3: fix strscpy causing content truncation issue Jijie Shao
2023-08-09 7:03 ` Leon Romanovsky
2023-08-10 7:45 ` Jijie Shao
2023-08-10 17:22 ` Jakub Kicinski [this message]
2023-08-10 18:23 ` Kees Cook
2023-08-10 18:47 ` Jakub Kicinski
2023-08-11 2:28 ` Jijie Shao
2023-08-13 9:05 ` Leon Romanovsky
2023-08-10 18:50 ` patchwork-bot+netdevbpf
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=20230810102247.699ddc14@kernel.org \
--to=kuba@kernel.org \
--cc=chenhao418@huawei.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=keescook@chromium.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liuyonglong@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=salil.mehta@huawei.com \
--cc=shaojijie@huawei.com \
--cc=shenjian15@huawei.com \
--cc=stable@vger.kernel.org \
--cc=wangjie125@huawei.com \
--cc=yisen.zhuang@huawei.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).