linux-kernel - Re: kernfs: Prefer strscpy over strlcpy calls

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]

Message-ID: <CADmuW3VngW3ineOjUNLYQT1UXsW-s46HjLKx0H3JyexKMtUhQA@mail.gmail.com>
Date:   Wed, 10 May 2023 16:48:23 -0400
From:   Azeem Shaikh <azeemshaikh38@...il.com>
To:     Linus Torvalds <torvalds@...uxfoundation.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Tejun Heo <tj@...nel.org>, security@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: kernfs: Prefer strscpy over strlcpy calls

> Absolutely not.
>
> This makes the whole exercise pointless.
>
> The reason to use strscpy() is to *avoid* doing the strlen() on the
> source, and limit things to the limited size.
>
> If you need to do the strlen(), then use strlcpy(). It's a broken
> interface, but creating this kind of horror wrapper that does the same
> thing as strlcpy() is worse than just using the regular version.
>
> So the strscpy() conversion should *only* be done if the caller
> doesn't care about the difference in return values (or done *together*
> with changing the caller to use the nicer strscpy() return value).
>
> It's also worth noting that 'strscpy()' not only returns a negative
> error value when the string doesn't fit - it will also possibly do the
> copy one word at a time, and may write extra zeroes at the end of the
> destination (all within the given size, of course).
>
> So strscpy() is _different_ from strlcpy(), and the conversion should
> not be done unless those differences are ok.

Thanks Linus, that helps clarify a lot. I traced the usage of these
functions across the kernel and plan to do direct replacement only
where it's safe (see thread here:
https://lore.kernel.org/all/CADmuW3XiYpGK7BessXJWjGnnxZti_3mawDSX7QPawsfmATxCng@mail.gmail.com/).
Let me know if that works for you.