Re: [PATCH v5 05/12] seq_buf: Clear what a writer did not claim when a seq_buf overflows

[Kees Cook <kees@kernel.org>]

On Mon, Oct 05, 2026 at 07:59:26PM +0100, David Laight wrote:
> >  static inline void
> >  seq_buf_set_overflow(struct seq_buf *s)
> >  {
> > +	if (s->len < s->size)
> > +		memset(s->buffer + s->len, 0, s->size - s->len);
>
> What is the performance impact of zeroing the buffer?

Overflow is never a fast path: it happens at most once per seq_buf
(after that len > size, so the memset is skipped), and it is already a
failure the caller has to handle.

It is also usually zero bytes. printf, bprintf, puts, putmem, and putc
all fill to the end before overflowing, so len == size and there is
nothing to clear. Only a writer handed the tail by seq_buf_get_buf()
that then gives up leaves anything behind (seq_buf_path() with d_path(),
or landlock's string_escape_mem()), and then the clear covers only the
space that writer was given, which it may have partly filled.

> I don't think it would be a good idea to be zeroing the buffer on entry
> either (I've not looked to see it that happens - but there will be PAGE_SIZE
> buffers (maybe 64k) that get a a small number of characters written to them).

Agreed, and it doesn't: seq_buf_init() writes a single NUL.

> Writing a single '\0' really ought to be enough.

It would be for seq_buf_str(), but once a seq_buf has overflowed,
seq_buf_used() reports the whole buffer, and seq_buf_print_seq() and
seq_buf_to_user() copy that many bytes. Whatever followed the NUL (the
path fragment d_path() left at the end, say) would still reach the
seq_file or userspace.

-Kees

-- 
Kees Cook