Hi, On Mon, Jan 9, 2023, at 20:45, yang.yang29@xxxxxxxxxx wrote: > From: Xu Panda <xu.panda@xxxxxxxxxx> > > 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@xxxxxxxxxx> > Signed-off-by: Yang Yang <yang.yang29@xxxxxxxxxx> > --- > 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
