On Sat, 16 May 2026 17:28:19 +0200 Heiko Carstens <[email protected]> wrote:
> On Thu, May 14, 2026 at 09:31:46AM -0700, Kees Cook wrote: > > On Thu, May 14, 2026 at 06:26:53PM +0200, Manuel Ebner wrote: > > > add strlcat and alternatives > > > > > > Signed-off-by: Manuel Ebner <[email protected]> > > > --- > > > Documentation/process/deprecated.rst | 7 +++++++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/Documentation/process/deprecated.rst > > > b/Documentation/process/deprecated.rst > > > index fed56864d036..06e802f4bbfd 100644 > > > --- a/Documentation/process/deprecated.rst > > > +++ b/Documentation/process/deprecated.rst > > > @@ -153,6 +153,13 @@ used, and the destinations should be marked with the > > > `__nonstring > > > attribute to avoid future compiler warnings. For cases still needing > > > NUL-padding, strtomem_pad() can be used. > > > > > > +strlcat() > > > +--------- > > > +strlcat() must re-scan the destination string from the beginning on each > > > +call (O(n^2) behavior). Alternatives are seq_buf_puts() and > > > seq_buf_printf(). > > > +snprintf(), scnprintf() and sysfs_emit() are possible aswell, but the > > > adoption > > > +of the arguments needs to be taken care off. > > > + > > > > How about just: > > > > strlcat() must re-scan the destination string from the beginning on each > > call (O(n^2) behavior). Use the seq_buf API or similar instead. > > seq_buf API for appending something to e.g. boot_command_line seems to be odd, > since boot_command_line is usually "just there" (depending on architecture and > boot loader). Indeed, but ISTR that code uses strcat() a lot of the time. The lengths are all known, so memcpy() can be used. I don't really see why strlcat() should be deprecated. Clearly there are many cases where there are better ways to do things. The only problem with strlcat() is that it returns the 'required length'. So there are some broken uses. - fs/nfs/flexfilelayout/flexfilelayout.c - lib/kunit/string-stream.c (although the preceding vsnprintf() looks like the actual bug). There is also some very strange code in security/selinus/ima.c - but it may be ok. In reality the return value of strlcat() isn't really much worse that that of snprintf(). -- David > > So if I would remove strlcat() from appending something to boot_command_line I > would end up open-coding strlcat(), including the chance for the usual > off-by-one bugs. Looks like this would be true for nearly all architectures. > > Is performance really the only reason to deprecate strlcat()? This seems to be > a bit questionable to me.
