linux-kernel - Re: [PATCH] kdb: prefer strlcpy to strncpy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAH7mPvhQo5S5EbgvkteoL1xftLWjWBqkfoanG0dTLzaa=FtTgw@mail.gmail.com>
Date:   Tue, 29 May 2018 19:01:35 -0700
From:   Nick Desaulniers <nick.desaulniers@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Jason Wessel <jason.wessel@...driver.com>,
        Daniel Thompson <daniel.thompson@...aro.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Baolin Wang <baolin.wang@...aro.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        kgdb-bugreport@...ts.sourceforge.net,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ebiggers@...gle.com
Subject: Re: [PATCH] kdb: prefer strlcpy to strncpy

On Tue, May 29, 2018 at 12:57 AM, Arnd Bergmann <arnd@...db.de> wrote:
> On Tue, May 29, 2018 at 7:57 AM, Nick Desaulniers
> <nick.desaulniers@...il.com> wrote:
>> Fixes stringop-truncation and stringop-overflow warnings from gcc-8.
>
> That patch description should really explain whether gcc is right or not. What's
> the worst thing that could happen here?
>
> I would also recommend citing the exact warning you got.
>
>> diff --git a/kernel/debug/kdb/kdb_io.c b/kernel/debug/kdb/kdb_io.c
>> index ed5d349..b5dfff1 100644
>> --- a/kernel/debug/kdb/kdb_io.c
>> +++ b/kernel/debug/kdb/kdb_io.c
>> @@ -443,7 +443,7 @@ static char *kdb_read(char *buffer, size_t bufsize)
>>  char *kdb_getstr(char *buffer, size_t bufsize, const char *prompt)
>>  {
>>         if (prompt && kdb_prompt_str != prompt)
>> -               strncpy(kdb_prompt_str, prompt, CMD_BUFLEN);
>> +               strlcpy(kdb_prompt_str, prompt, CMD_BUFLEN);
>>         kdb_printf(kdb_prompt_str);
>>         kdb_nextline = 1;       /* Prompt and input resets line number */
>>         return kdb_read(buffer, bufsize);
>> diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
>> index e405677..c30a0d8 100644
>> --- a/kernel/debug/kdb/kdb_main.c
>> +++ b/kernel/debug/kdb/kdb_main.c
>> @@ -1103,12 +1103,12 @@ static int handle_ctrl_cmd(char *cmd)
>>         case CTRL_P:
>>                 if (cmdptr != cmd_tail)
>>                         cmdptr = (cmdptr-1) % KDB_CMD_HISTORY_COUNT;
>> -               strncpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
>> +               strlcpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
>>                 return 1;
>>         case CTRL_N:
>>                 if (cmdptr != cmd_head)
>>                         cmdptr = (cmdptr+1) % KDB_CMD_HISTORY_COUNT;
>> -               strncpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
>> +               strlcpy(cmd_cur, cmd_hist[cmdptr], CMD_BUFLEN);
>>                 return 1;
>>         }
>>         return 0;
>
> Those three all look good.
>
>> diff --git a/kernel/debug/kdb/kdb_support.c b/kernel/debug/kdb/kdb_support.c
>> index 990b3cc..dcfbf8f 100644
>> --- a/kernel/debug/kdb/kdb_support.c
>> +++ b/kernel/debug/kdb/kdb_support.c
>> @@ -236,7 +236,7 @@ int kallsyms_symbol_next(char *prefix_name, int flag)
>>
>>         while ((name = kdb_walk_kallsyms(&pos))) {
>>                 if (strncmp(name, prefix_name, prefix_len) == 0) {
>> -                       strncpy(prefix_name, name, strlen(name)+1);
>> +                       strlcpy(prefix_name, name, prefix_len);
>>                         return 1;
>>                 }
>
> I don't know what this does, but you are changing the behavior: the previous
> 'strlen(name)+1' argument was the size of the source string (which makes
> the strncpy() behave the same as a plain strcpy()), the new one means
> we only copy at most as many bytes as the previous length of the destination
> string.
>
> Is that intended? If yes, better explain it in the patch description.
>
>         Arnd

Eric points out that this will leak kernel memory if size is less than
sizeof src.