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

[Kees Cook]

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).

-Kees

-- 
Kees Cook