[PATCH linux-next] ALSA: control-led: use strscpy() to instead of strncpy()

[Takashi Sakamoto]

Hi,

On Mon, Jan 9, 2023, at 20:45, yang.yang29 at zte.com.cn wrote:
> From: Xu Panda <xu.panda at zte.com.cn>
>
> The implementation of strscpy() is more robust and safer.
> That's now the recommended way to copy NUL-terminated strings.
>
> Signed-off-by: Xu Panda <xu.panda at zte.com.cn>
> Signed-off-by: Yang Yang <yang.yang29 at zte.com.cn>
> ---
>  sound/core/control_led.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/sound/core/control_led.c b/sound/core/control_led.c
> index f975cc85772b..c88653c205eb 100644
> --- a/sound/core/control_led.c
> +++ b/sound/core/control_led.c
> @@ -534,8 +534,7 @@ static ssize_t set_led_id(struct snd_ctl_led_card 
> *led_card, const char *buf, si
>  	struct snd_ctl_elem_id id;
>  	int err;
>
> -	strncpy(buf2, buf, len);
> -	buf2[len] = '\0';
> +	strncpy(buf2, buf, len + 1);

The patch comment refers to strscpy(), however strncpy() is still used. I wonder
whether it is the intension of this patch. I think any trouble happended.

Anyway I'm for usage of strscpy() as the comment.

>  	memset(&id, 0, sizeof(id));
>  	id.iface = SNDRV_CTL_ELEM_IFACE_MIXER;
>  	s = buf2;
> -- 
> 2.15.2

As another issue, I can see that the local variable, len, can bring buffer overrun
over buf2[256] since it has maximum value between the size of pointer and count
argument. Maricious user space application can attack as long as it has write
permission to the device attributes. I guess kernel stack can be broken by the
attack.

```
532    char buf2[256], *s, *os;
533    size_t len = max(sizeof(s) - 1, count);
...
537    strncpy(buf2, buf, len);
```

I'm already in bed today, so I hope anyone posts fix, or waiting tomorrow.


Regards

Takashi Sakamoto