linux-hardening - Re: [PATCH] nios2: Replace all non-returning strlcpy with strscpy

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] [day] [month] [year] [list]

Date:   Tue, 20 Jun 2023 17:14:57 -0700
From:   Kees Cook <kees@...nel.org>
To:     Dinh Nguyen <dinguyen@...nel.org>,
        Kees Cook <keescook@...omium.org>
CC:     Azeem Shaikh <azeemshaikh38@...il.com>,
        linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] nios2: Replace all non-returning strlcpy with strscpy

On June 20, 2023 3:27:29 PM PDT, Dinh Nguyen <dinguyen@...nel.org> wrote:
>
>
>On 6/20/23 15:15, Kees Cook wrote:
>> On Tue, Jun 13, 2023 at 05:15:41PM -0500, Dinh Nguyen wrote:
>>> 
>>> 
>>> On 5/30/23 18:20, Kees Cook wrote:
>>>> On Tue, May 30, 2023 at 04:23:58PM +0000, Azeem Shaikh wrote:
>>>>> strlcpy() reads the entire source buffer first.
>>>>> This read may exceed the destination size limit.
>>>>> This is both inefficient and can lead to linear read
>>>>> overflows if a source string is not NUL-terminated [1].
>>>>> In an effort to remove strlcpy() completely [2], replace
>>>>> strlcpy() here with strscpy().
>>>>> No return values were used, so direct replacement is safe.
>>>>> 
>>>>> [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy
>>>>> [2] https://github.com/KSPP/linux/issues/89
>>>>> 
>>>>> Signed-off-by: Azeem Shaikh <azeemshaikh38@...il.com>
>>>> 
>>>> Reviewed-by: Kees Cook <keescook@...omium.org>
>>>> 
>>> 
>>> Applied!
>> 
>> Thanks for taking this patch! I just wanted to double-check, though; I
>> haven't seen it show up in -next yet. Is this still queued?
>> 
>> Thanks!
>
>I've queued it for v6.5. Do you need it in v6.4?

6.5 is fine, yeah. I just wanted to make sure it didn't get lost. :) (I didn't see it in sfr's linux-next merges tree.)

Thanks!

-Kees



-- 
Kees Cook