On Fri, Mar 20, 2026 at 09:25:41PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 20, 2026 at 12:17:54PM -0700, Kees Cook wrote:
> > On Mon, Mar 16, 2026 at 06:01:58PM +0100, Andy Shevchenko wrote:
> > > strlcpy() and strlcat() are confusing APIs and the former one already gone
> > > from the kernel. In preparation to kill strlcat() replace it with the
> > > better
> > > alternative.
> >
> > Yes please. There are a few places I looked at in the past that might
> > benefit from being changed to seq_buf or similar (where snprintf doesn't
> > cut it), but otherwise the removal of strlcat should be straight forward
> > and would be well appreciated. :)
>
> Thank you for confirming, this is basically the message to Josh to find
> users and start converting them and kill strlcat() eventually. Josh, as
> you see it will be well appreciated!
As an example of a seq_buf user, see block/partitions/core.c:
static struct parsed_partitions *check_partition(struct gendisk *hd)
{
...
state->pp_buf = (char *)__get_free_page(GFP_KERNEL);
...
state->pp_buf[0] = '\0';
...
snprintf(state->pp_buf, PAGE_SIZE, " %s:", state->name);
...
while (!res && check_part[i]) {
...
res = check_part[i++](state);
...
All the partition handlers then use strlcat to append more details,
and it's totally unbounded. The correct thing would be to build a
seq_buf to attach to state instead of the pp_buf, and the handlers would
use seq_buf functions to append their info, etc etc.
-Kees
--
Kees Cook
