Re: [PATCH] params: Replace deprecated strcpy() with strscpy()

Re: [PATCH] params: Replace deprecated strcpy() with strscpy()

[Petr Pavlu]

On 8/10/25 11:44 PM, Thorsten Blum wrote:
> strcpy() is deprecated; use strscpy() instead.
> 
> Link: https://github.com/KSPP/linux/issues/88
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
>  kernel/params.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/params.c b/kernel/params.c
> index b92d64161b75..88765f2d5d56 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -513,13 +513,14 @@ EXPORT_SYMBOL(param_array_ops);
>  int param_set_copystring(const char *val, const struct kernel_param *kp)
>  {
>  	const struct kparam_string *kps = kp->str;
> +	const size_t len = strnlen(val, kps->maxlen);
>  
> -	if (strnlen(val, kps->maxlen) == kps->maxlen) {
> +	if (len == kps->maxlen) {
>  		pr_err("%s: string doesn't fit in %u chars.\n",
>  		       kp->name, kps->maxlen-1);
>  		return -ENOSPC;
>  	}
> -	strcpy(kps->string, val);
> +	strscpy(kps->string, val, len + 1);
>  	return 0;
>  }

Since the code already calculated the length of val and that it fits
into kps->string, is there any advantage (or disadvantage) to using
strscpy() over memcpy()?

>  EXPORT_SYMBOL(param_set_copystring);
> @@ -841,7 +842,7 @@ static void __init param_sysfs_builtin(void)
>  		dot = strchr(kp->name, '.');
>  		if (!dot) {
>  			/* This happens for core_param() */
> -			strcpy(modname, "kernel");
> +			strscpy(modname, "kernel");
>  			name_len = 0;
>  		} else {
>  			name_len = dot - kp->name + 1;

I think this can go through the modules tree. I've CC'd the mailing
list.

-- 
Thanks,
Petr

Re: [PATCH] params: Replace deprecated strcpy() with strscpy()

[Thorsten Blum]

Hi Petr,

On 13. Aug 2025, at 10:59, Petr Pavlu wrote:
> Since the code already calculated the length of val and that it fits
> into kps->string, is there any advantage (or disadvantage) to using
> strscpy() over memcpy()?

strscpy() guarantees that the destination buffer 'kps->string' is always
NUL-terminated, even if the source 'val' is not. memcpy() just copies
the bytes as they are.

If it were guaranteed that 'val' is always NUL-terminated, memcpy()
would be fine too, but since param_set_copystring() is exported, we
probably can't make that assumption.

> I think this can go through the modules tree. I've CC'd the mailing
> list.

Thanks,
Thorsten

Re: [PATCH] params: Replace deprecated strcpy() with strscpy()

[Petr Pavlu]

On 8/13/25 11:33 AM, Thorsten Blum wrote:
> Hi Petr,
> 
> On 13. Aug 2025, at 10:59, Petr Pavlu wrote:
>> Since the code already calculated the length of val and that it fits
>> into kps->string, is there any advantage (or disadvantage) to using
>> strscpy() over memcpy()?
> 
> strscpy() guarantees that the destination buffer 'kps->string' is always
> NUL-terminated, even if the source 'val' is not. memcpy() just copies
> the bytes as they are.
> 
> If it were guaranteed that 'val' is always NUL-terminated, memcpy()
> would be fine too, but since param_set_copystring() is exported, we
> probably can't make that assumption.

The function param_set_copystring() checks using
'strnlen(val, kps->maxlen) == kps->maxlen' if val contains NUL in the
first kps->maxlen bytes. It can use memcpy() instead of strscpy() to
avoid repeating this work.

-- Petr

Re: [PATCH] params: Replace deprecated strcpy() with strscpy()

[Thorsten Blum]

On 13. Aug 2025, at 13:42, Petr Pavlu wrote:
> On 8/13/25 11:33 AM, Thorsten Blum wrote:
>> On 13. Aug 2025, at 10:59, Petr Pavlu wrote:
>>> Since the code already calculated the length of val and that it fits
>>> into kps->string, is there any advantage (or disadvantage) to using
>>> strscpy() over memcpy()?
>> 
>> strscpy() guarantees that the destination buffer 'kps->string' is always
>> NUL-terminated, even if the source 'val' is not. memcpy() just copies
>> the bytes as they are.
>> 
>> If it were guaranteed that 'val' is always NUL-terminated, memcpy()
>> would be fine too, but since param_set_copystring() is exported, we
>> probably can't make that assumption.
> 
> The function param_set_copystring() checks using
> 'strnlen(val, kps->maxlen) == kps->maxlen' if val contains NUL in the
> first kps->maxlen bytes. It can use memcpy() instead of strscpy() to
> avoid repeating this work.

I see, and yes

	memcpy(kps->string, val, len + 1);

would then be slightly more efficient because strscpy() would just
recompute the length before calling memcpy() internally.

I'll submit a v2.

Thanks,
Thorsten