Re: [PATCH 0/7] ALSA: remove remaining strlcat() users under sound/

On Fri, 7 Aug 2026 14:46:44 -0700
Kees Cook <[email protected]> wrote:

> On Fri, Aug 07, 2026 at 06:03:58PM +0200, Takashi Iwai wrote:
> > If strlcat() were super-dangerous, it's understandable to drop.  But,
> > it's not, and issues discussed in the github are minor and something
> > that can be addressed in strlcat() implementation; that is, can't we
> > rather re-implement strlcat() in a safer way, instead of killing it?
> > 
> > Sure, there are code calling strlcat() that could be optimized better.
> > They can be cleaned up.  But it alone can't be a reason that strlcat()
> > must die without mercy.  
> 
> The risk comes from the compiler having no way to know what the size of
> the destination buffer is, as the "char *" argument has no length
> associated with it. One thing we can do is change the argument
> requirements for strlcat (like we did when designing memtostr, etc),
> that requires that the argument explicitly be an array (not a string
> pointer), at which point bounds checking can be done.
> 
> Usually this requires changing the plumbing of arguments, as a lot of C
> code is used to just passing around a bare "char *", etc. And if that
> re-plumbing is going to happen, it might as well be seq_buf.
> 
> But yes, just replacing it with strlen/strscpy isn't very ergonomic.
> Adding the length explicitly with strscpy certainly gets us the bounds
> again, but it's _separate_ from the string still, and that will lead to
> mistakes too. Better to have it be part of the type (i.e. either an
> array or seq_buf).

And, if the destination is an array (where the compiler knows the size)
there is nothing wrong with a 2 argument function.

Like strscpy() you want any result to be the new length of the destination
string.

Embedding a fixed length char[] in a struct can be a simple better option
and lets the compiler do a lot of the checks for you.

	David

> 
> -Kees
>