All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "Bill Wendling" <morbo@google.com>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"David Gow" <david@davidgow.net>,
	"Petr Mladek" <pmladek@suse.com>,
	"Shuvam Pandey" <shuvampandey1@gmail.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Sergey Senozhatsky" <senozhatsky@chromium.org>,
	"Günther Noack" <gnoack@google.com>,
	"Mickaël Salaün" <mic@digikod.net>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
	"Jiri Kosina" <jikos@kernel.org>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Eduard Zingerman" <eddyz87@gmail.com>,
	"Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
	"Martin KaFai Lau" <martin.lau@linux.dev>,
	"Song Liu" <song@kernel.org>,
	"Yonghong Song" <yonghong.song@linux.dev>,
	"Jiri Olsa" <jolsa@kernel.org>,
	"Emil Tsalapatis" <emil@etsalapatis.com>,
	"Ihor Solodrai" <ihor.solodrai@linux.dev>,
	"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
	"Uwe Kleine-König" <u.kleine-koenig@baylibre.com>,
	"Madhavan Srinivasan" <maddy@linux.ibm.com>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Shivaprasad G Bhat" <sbhat@linux.ibm.com>,
	"Thorsten Blum" <blum@kernel.org>,
	"Alison Schofield" <alison.schofield@intel.com>,
	"Dave Jiang" <dave.jiang@intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Guangshuo Li" <lgs201920130244@gmail.com>,
	"Ira Weiny" <iweiny@kernel.org>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Vishal Verma" <vishal.l.verma@intel.com>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Shuah Khan" <skhan@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, nvdimm@lists.linux.dev,
	linux-doc@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v4 05/11] seq_buf: Add seq_buf_strlen()
Date: Sun, 4 Oct 2026 00:26:39 -0700	[thread overview]
Message-ID: <202610040023.A3865A6@keescook> (raw)
In-Reply-To: <asEhEe0Urb5Wx7yi@ashevche-desk.local>

On Sat, Oct 03, 2026 at 06:36:49PM +0300, Andy Shevchenko wrote:
> On Fri, Oct 02, 2026 at 08:59:10PM -0700, Kees Cook wrote:
> > Several strlcat() call sites being converted to seq_buf need behavior
> > seq_buf doesn't currently provide. The return from seq_buf_used() is
> > not the length of the string in a seq_buf. Once the buffer is full or
> > has overflowed it returns the buffer size, which counts the byte that
> > seq_buf_str() replaces with the NUL, so a caller that needs the string
> > and its length has to call seq_buf_str() and then walk the string with
> > strlen().
> > 
> > Move the termination out of seq_buf_str() into a helper that returns
> > where it put the NUL, and add seq_buf_strlen(), which terminates the
> > buffer in the same way and returns that offset.
> > 
> > As discussed in review, don't add WARN_ON() for seq_buf_strlen() and
> > drop it from seq_buf_str().
> > 
> > Add tests comparing seq_buf_strlen() against strlen() of seq_buf_str()
> > for empty, appended, truncated, exactly full, and overflowed buffers,
> > checking that seq_buf_strlen() alone terminates a full buffer, and
> > checking that a zero-sized seq_buf reports an empty string from both
> > accessors without touching the buffer.
> > 
> > Tests passed under qemu on ARCH=x86_64 with GCC 16.2.0 and CONFIG_KASAN=y,
> > and on big-endian ARCH=s390 with GCC s390x-linux-gnu 16.2.0.
> 
> ...
> 
> >  static inline const char *seq_buf_str(struct seq_buf *s)
> >  {
> > -	if (WARN_ON(s->size == 0))
> > +	if (s->size == 0)
> >  		return "";
> >  
> > -	if (seq_buf_buffer_left(s))
> > -		s->buffer[s->len] = 0;
> > -	else
> > -		s->buffer[s->size - 1] = 0;
> > +	__seq_buf_terminate(s);
> >  
> >  	return s->buffer;
> >  }
> 
> Looking at this again, can't it be rewritten now using _strlen()?
> 
> 	if (seq_buf_strlen(s))
> 		return s->buffer;
> 
> 	return "";
> 
> ?

It could, but I'm vaguely nervous about the difference between
	s->buffer[0] == '\0'
and
	.data ""

i.e. we only force the return of seq_buf_str() to be _not_ just
s->buffer when s->buffer is weirdly impossible (due to size == 0).
I'd rather not make all 0-len strings return the .data segment's const
"" string...

-- 
Kees Cook

  reply	other threads:[~2026-10-04  7:26 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-03  3:59 [PATCH v4 00/11] seq_buf: Add seq_buf_strlen() Kees Cook
2026-10-03  3:59 ` [PATCH v4 01/11] seq_buf: Do not print an empty line from an overflowed seq_buf_do_printk() Kees Cook
2026-10-03  4:07   ` sashiko-bot
2026-10-03  4:50   ` bot+bpf-ci
2026-10-03  4:50     ` bot+bpf-ci
2026-10-05 10:05     ` Kees Cook
2026-10-03  3:59 ` [PATCH v4 02/11] seq_buf: Do not pop from an overflowed seq_buf Kees Cook
2026-10-03  4:05   ` sashiko-bot
2026-10-03  3:59 ` [PATCH v4 03/11] seq_buf: Copy what fits when seq_buf_puts() and seq_buf_putmem() overflow Kees Cook
2026-10-03  4:07   ` sashiko-bot
2026-10-03  4:50   ` bot+bpf-ci
2026-10-03  4:50     ` bot+bpf-ci
2026-10-05 10:06     ` Kees Cook
2026-10-03  3:59 ` [PATCH v4 04/11] seq_buf: Clear what a writer did not claim when a seq_buf overflows Kees Cook
2026-10-03  4:07   ` sashiko-bot
2026-10-03  4:50   ` bot+bpf-ci
2026-10-03  4:50     ` bot+bpf-ci
2026-10-03  3:59 ` [PATCH v4 05/11] seq_buf: Add seq_buf_strlen() Kees Cook
2026-10-03  4:04   ` sashiko-bot
2026-10-03 15:36   ` Andy Shevchenko
2026-10-04  7:26     ` Kees Cook [this message]
2026-10-04  8:34       ` Andy Shevchenko
2026-10-05 11:22         ` Kees Cook
2026-10-05 11:34           ` Alejandro Colomar
2026-10-05 15:58             ` Kees Cook
2026-10-05 16:43               ` Alejandro Colomar
2026-10-03  3:59 ` [PATCH v4 06/11] seq_buf: Add seq_buf_terminate() Kees Cook
2026-10-03  4:05   ` sashiko-bot
2026-10-03  3:59 ` [PATCH v4 07/11] bpf: Remove dead newline stripping from format_disasm_line() Kees Cook
2026-10-03  4:05   ` sashiko-bot
2026-10-03  3:59 ` [PATCH v4 08/11] seq_buf: Add seq_buf_init_append() Kees Cook
2026-10-03  4:05   ` sashiko-bot
2026-10-03  4:33   ` bot+bpf-ci
2026-10-03  4:33     ` bot+bpf-ci
2026-10-03 10:31     ` Kees Cook
2026-10-03  3:59 ` [PATCH v4 09/11] powerpc/papr_scm: Return the string length from the sysfs show functions Kees Cook
2026-10-03  4:06   ` sashiko-bot
2026-10-03  3:59 ` [PATCH v4 10/11] nvdimm: ndtest: Return the string length from flags_show() Kees Cook
2026-10-03  4:08   ` sashiko-bot
2026-10-03  3:59 ` [PATCH v4 11/11] docs: core-api: Document the seq_buf API Kees Cook
2026-10-03  4:03   ` sashiko-bot
2026-10-03  6:32 ` [PATCH v4 00/11] seq_buf: Add seq_buf_strlen() Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202610040023.A3865A6@keescook \
    --to=kees@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alison.schofield@intel.com \
    --cc=andrii@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=ast@kernel.org \
    --cc=blum@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=chleroy@kernel.org \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=dave.jiang@intel.com \
    --cc=david@davidgow.net \
    --cc=eddyz87@gmail.com \
    --cc=emil@etsalapatis.com \
    --cc=gnoack@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=ihor.solodrai@linux.dev \
    --cc=iweiny@kernel.org \
    --cc=jikos@kernel.org \
    --cc=jolsa@kernel.org \
    --cc=lgs201920130244@gmail.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=martin.lau@linux.dev \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=memxor@gmail.com \
    --cc=mhiramat@kernel.org \
    --cc=mic@digikod.net \
    --cc=morbo@google.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=nvdimm@lists.linux.dev \
    --cc=pmladek@suse.com \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sbhat@linux.ibm.com \
    --cc=senozhatsky@chromium.org \
    --cc=shuvampandey1@gmail.com \
    --cc=skhan@linuxfoundation.org \
    --cc=song@kernel.org \
    --cc=u.kleine-koenig@baylibre.com \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=vishal.l.verma@intel.com \
    --cc=willy@infradead.org \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.