From: Kees Cook <kees@kernel.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Bill Wendling <morbo@google.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.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>,
nikitash.mariiaw@gmail.com, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2 5/9] seq_buf: Add seq_buf_strlen()
Date: Tue, 29 Sep 2026 19:28:44 -0700 [thread overview]
Message-ID: <202609291927.9D27E60@keescook> (raw)
In-Reply-To: <2026092037-antsy-shrapnel-6139@gregkh>
On Sun, Sep 20, 2026 at 06:34:32AM +0100, Greg KH wrote:
> WARN on the init makes more sense, but even then it feels odd as if we
> wanted to make a seq_buf with data from a device or userspace, we would
> have to verify the size is non-zero _before_ creating the seq_buf or we
> would crash. So someone has to check the "untrusted" data somewhere,
> right?
>
> And why can't we have buffers of 0 size work just fine? What prevents
> that? People have "empty" strings for lots of things.
Yeah, okay. I'll not add the WARN for seq_buf_strlen() and remove it
from seq_buf_str().
-Kees
--
Kees Cook
next prev parent reply other threads:[~2026-09-30 2:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-19 0:26 [PATCH v2 0/9] seq_buf: Add seq_buf_strlen() Kees Cook
2026-09-19 0:26 ` [PATCH v2 1/9] seq_buf: Do not print an empty line from an overflowed seq_buf_do_printk() Kees Cook
2026-09-19 0:27 ` [PATCH v2 2/9] seq_buf: Do not pop from an overflowed seq_buf Kees Cook
2026-09-19 0:34 ` sashiko-bot
2026-09-19 0:27 ` [PATCH v2 3/9] seq_buf: Copy what fits when seq_buf_puts() and seq_buf_putmem() overflow Kees Cook
2026-09-19 0:27 ` [PATCH v2 4/9] seq_buf: Clear what a writer did not claim when a seq_buf overflows Kees Cook
2026-09-19 0:27 ` [PATCH v2 5/9] seq_buf: Add seq_buf_strlen() Kees Cook
2026-09-19 7:38 ` Greg KH
2026-09-19 21:15 ` Kees Cook
2026-09-20 5:34 ` Greg KH
2026-09-20 8:58 ` David Laight
2026-09-30 2:28 ` Kees Cook [this message]
2026-09-21 9:46 ` Steven Rostedt
2026-09-30 2:31 ` Kees Cook
2026-09-19 0:27 ` [PATCH v2 6/9] seq_buf: Add seq_buf_init_append() Kees Cook
2026-09-19 0:27 ` [PATCH v2 7/9] powerpc/papr_scm: Return the string length from the sysfs show functions Kees Cook
2026-09-19 0:27 ` [PATCH v2 8/9] nvdimm: ndtest: Return the string length from flags_show() Kees Cook
2026-09-19 0:27 ` [PATCH v2 9/9] docs: core-api: Document the seq_buf API Kees Cook
2026-09-19 1:54 ` Randy Dunlap
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=202609291927.9D27E60@keescook \
--to=kees@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=david@davidgow.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=morbo@google.com \
--cc=nikitash.mariiaw@gmail.com \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=shuvampandey1@gmail.com \
--cc=willy@infradead.org \
/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.