On Sat, Sep 19, 2026 at 02:15:58PM -0700, Kees Cook wrote:
> On Sat, Sep 19, 2026 at 08:38:37AM +0100, Greg KH wrote:
> > On Fri, Sep 18, 2026 at 05:27:03PM -0700, Kees Cook wrote:
> > > +static inline size_t seq_buf_strlen(struct seq_buf *s)
> > > +{
> > > + if (WARN_ON(s->size == 0))
> > > + return 0;
> >
> > Why WARN_ON()? Are you wanting to just mint new CVEs with this code
> > path, do we not give out enough already? :)
> >
> > I can see returning 0, if it's empty, but isn't that a valid check for
> > people to wish to know at times? Why crash the box? (remember about
> > panic-on-warn being enabled in a few billion Linux instances...)
>
> We have to figure out a line somewhere. :P Making a seq_buf with size 0
> is a nonsense construction, but seq_buf_init is non-allocating, so
> there's no feedback about setting it to size 0. We could move the WARN
> to the init? I was just following the existing style here.
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.
thanks,
greg k-h
