On Fri, Aug 25, 2023 at 07:13:42AM +0200, Michael Straube wrote: > On 8/10/23 07:01, Dan Carpenter wrote: > > On Wed, Aug 09, 2023 at 08:02:05PM +0200, Michael Straube wrote: > > > On 8/9/23 14:21, Greg KH wrote: > > > > On Sat, Aug 05, 2023 at 09:51:14AM +0200, Michael Straube wrote: > > > > > Replace strncpy with strscpy in two places where the destination buffer > > > > > should be NUL-terminated. Found by checkpatch. > > > > > > > > > > WARNING: Prefer strscpy, strscpy_pad, or __nonstring over strncpy - see: https://github.com/KSPP/linux/issues/90 > > > > > > > > If a global search/replace could be done, it would have happend a long > > > > time ago. > > > > > > > > How was this tested? The functions work differently, are you sure there > > > > is no change in functionality here? > > > > > > > > > > It was only compile tested. To me it looked as it does not change > > > functionality, but looking a bit deeper at it I'm not sure anymore. > > > So, we should leave it as is. > > > > So there are three main differences between strncpy() and strcpy(). > > > > 1) The return. > > 2) strncpy() will always write net->hidden_ssid_len bytes. If the > > string to copy is smaller than net->hidden_ssid_len bytes it will > > fill the rest with zeroes. This can be important for preventing > > information leaks. > > 3) strscpy() will always add a NUL terminator where strncpy() just > > truncates a too long string without adding a terminator. > > > > We want #3. We don't care about #1. The only thing to check is #2. > > > > regards, > > dan carpenter > > > > Thank you Dan, > > so in this case we should/could replace strncpy with strscpy_pad, > correct? I'm pretty sure that strscpy() was correct. It requires some analysis in how this is initialized and/or used. Don't just automatically use strscpy_pad() to try avoid doing the analysis. ;) regards, dan carpenter
