From: "luobin (L)" <luobin9@huawei.com>
To: Kees Cook <keescook@chromium.org>
Cc: David Miller <davem@davemloft.net>, <David.Laight@ACULAB.COM>,
<linux-kernel@vger.kernel.org>, <netdev@vger.kernel.org>,
<luoxianjun@huawei.com>, <yin.yinshi@huawei.com>,
<cloud.wangxiaoyun@huawei.com>, <chiqijun@huawei.com>
Subject: Re: [PATCH net-next v1] hinic: fix strncpy output truncated compile warnings
Date: Sun, 9 Aug 2020 11:19:31 +0800 [thread overview]
Message-ID: <493cae67-6346-1a57-5cca-65a2b6d2aeba@huawei.com> (raw)
In-Reply-To: <202008072320.03879DAC@keescook>
On 2020/8/8 14:44, Kees Cook wrote:
> On Fri, Aug 07, 2020 at 08:42:43PM -0700, David Miller wrote:
>> From: "luobin (L)" <luobin9@huawei.com>
>> Date: Sat, 8 Aug 2020 11:36:42 +0800
>>
>>> On 2020/8/7 17:32, David Laight wrote:
>>>>> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
>>>>> b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
>>>>> index c6adc776f3c8..1ec88ebf81d6 100644
>>>>> --- a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
>>>>> +++ b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
>>>>> @@ -342,9 +342,9 @@ static int chip_fault_show(struct devlink_fmsg *fmsg,
>>>>>
>>>>> level = event->event.chip.err_level;
>>>>> if (level < FAULT_LEVEL_MAX)
>>>>> - strncpy(level_str, fault_level[level], strlen(fault_level[level]));
>>>>> + strncpy(level_str, fault_level[level], strlen(fault_level[level]) + 1);
>>>>
>>>> Have you even considered what that code is actually doing?
>> ...
>>> I'm sorry that I haven't got what you mean and I haven't found any defects in that code. Can you explain more to me?
>>
>> David is trying to express the same thing I was trying to explain to
>> you, you should use sizeof(level_str) as the third argument because
>> the code is trying to make sure that the destination buffer is not
>> overrun.
>>
>> If you use the strlen() of the source buffer, the strncpy() can still
>> overflow the destination buffer.
>>
>> Now do you understand?
>
> Agh, please never use strncpy() on NUL-terminated strings[1]. (You can
> see this ultimately gets passed down into devlink_fmsg_string_put()
> which expects NUL-terminated strings and does not require trailing
> NUL-padding (which if it did, should still never use strncpy(), but
> rather strscpy_pad()).
>
> But, as David Laight hints, none of this is needed. The entire buffer
> can be avoided (just point into the existing array of strings -- which
> should also be const). Add I see that one of the array sizes is wrong.
> Both use FAULT_TYPE_MAX, but one should be FAULT_LEVEL_MAX. And since
> "Unknown" can just be added to the array, do that and clamp the value
> since it's only used for finding the strings in the array.
>
> I would suggest this (totally untested):
>
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> index c6adc776f3c8..20bfb05896e5 100644
> --- a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> @@ -334,18 +334,12 @@ void hinic_devlink_unregister(struct hinic_devlink_priv *priv)
> static int chip_fault_show(struct devlink_fmsg *fmsg,
> struct hinic_fault_event *event)
> {
> - char fault_level[FAULT_TYPE_MAX][FAULT_SHOW_STR_LEN + 1] = {
> - "fatal", "reset", "flr", "general", "suggestion"};
> - char level_str[FAULT_SHOW_STR_LEN + 1] = {0};
> - u8 level;
> + const char * const level_str[FAULT_LEVEL_MAX + 1] = {
> + "fatal", "reset", "flr", "general", "suggestion",
> + [FAULT_LEVEL_MAX] = "Unknown"};
> + u8 fault_level;
> int err;
>
> - level = event->event.chip.err_level;
> - if (level < FAULT_LEVEL_MAX)
> - strncpy(level_str, fault_level[level], strlen(fault_level[level]));
> - else
> - strncpy(level_str, "Unknown", strlen("Unknown"));
> -
> if (level == FAULT_LEVEL_SERIOUS_FLR) {
> err = devlink_fmsg_u32_pair_put(fmsg, "Function level err func_id",
> (u32)event->event.chip.func_id);
> @@ -361,7 +355,8 @@ static int chip_fault_show(struct devlink_fmsg *fmsg,
> if (err)
> return err;
>
> - err = devlink_fmsg_string_pair_put(fmsg, "err_level", level_str);
> + fault_level = clamp(event->event.chip.err_level, FAULT_LEVEL_MAX);
> + err = devlink_fmsg_string_pair_put(fmsg, "err_level", fault_str[fault_level]);
> if (err)
> return err;
>
> @@ -381,18 +376,15 @@ static int chip_fault_show(struct devlink_fmsg *fmsg,
> static int fault_report_show(struct devlink_fmsg *fmsg,
> struct hinic_fault_event *event)
> {
> - char fault_type[FAULT_TYPE_MAX][FAULT_SHOW_STR_LEN + 1] = {
> + const char * const type_str[FAULT_TYPE_MAX + 1] = {
> "chip", "ucode", "mem rd timeout", "mem wr timeout",
> - "reg rd timeout", "reg wr timeout", "phy fault"};
> - char type_str[FAULT_SHOW_STR_LEN + 1] = {0};
> + "reg rd timeout", "reg wr timeout", "phy fault",
> + [FAULT_TYPE_MAX] = "Unknown"};
> + u8 fault_type;
> int err;
>
> - if (event->type < FAULT_TYPE_MAX)
> - strncpy(type_str, fault_type[event->type], strlen(fault_type[event->type]));
> - else
> - strncpy(type_str, "Unknown", strlen("Unknown"));
> -
> - err = devlink_fmsg_string_pair_put(fmsg, "Fault type", type_str);
> + fault_type = clamp(event->type, FAULT_TYPE_MAX);
> + err = devlink_fmsg_string_pair_put(fmsg, "Fault type", type_str[fault_type]);
> if (err)
> return err;
>
>
>
> -Kees
>
> [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings
>
Thanks for your explanation and review. I haven't realized using strncpy() on NUL-terminated strings is deprecated
and just trying to avoid the compile warnings. The website you provide helps me a lot. Thank you very much!
next prev parent reply other threads:[~2020-08-09 3:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-07 2:09 Luo bin
2020-08-07 9:32 ` David Laight
2020-08-08 3:36 ` luobin (L)
2020-08-08 3:42 ` David Miller
2020-08-08 6:44 ` Kees Cook
2020-08-09 3:19 ` luobin (L) [this message]
2020-08-10 8:15 ` David Laight
2020-08-09 2:59 ` luobin (L)
2020-08-08 12:50 ` David Laight
2020-08-09 3:35 ` luobin (L)
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=493cae67-6346-1a57-5cca-65a2b6d2aeba@huawei.com \
--to=luobin9@huawei.com \
--cc=David.Laight@ACULAB.COM \
--cc=chiqijun@huawei.com \
--cc=cloud.wangxiaoyun@huawei.com \
--cc=davem@davemloft.net \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luoxianjun@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=yin.yinshi@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
all inboxes | Powered by JetHome®