From: Alejandro Colomar <alx+linux-hardening@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Jiri Kosina <jkosina@suse.cz>, Petr Mladek <pmladek@suse.cz>,
Kees Cook <kees@kernel.org>,
linux-hardening@vger.kernel.org
Subject: seq_buf_used() return value on overflow
Date: Wed, 28 Oct 2026 21:59:39 +0100 [thread overview]
Message-ID: <auJfBNeZGDbvMBxS@devuan> (raw)
In-Reply-To: <auIrUV7A8eF8DCGG@devuan>
[-- Attachment #1: Type: text/plain, Size: 2427 bytes --]
Hi Steven,
Another question that arised while rewriting seq_buf.
There's seq_buf_used(), which replaced (in 2014) the previous
SEQ_BUF_USED(). That commit changed the value from
min((s)->len, (s)->size - 1)
to
min(s->len, s->size)
but didn't change any other code. I don't see any mentions about that
off-by-one change in the commit message. (There are two 'Link:' tags,
but I didn't see any discussion about this patch in those; they seem to
focus on other patches of the same set.)
I wonder, because when changing to use pointers, the good behavior would
be with the -1, so I wonder whether we can go back to the old behavior
easily, or if anything depends on that value. Was this a regression?
Or was it a silent fix? Or is it unimportant at the moment?
This is the commit that I'm talking about:
eeab98154dc0 (2014-11-19; "seq_buf: Create seq_buf_used() to find out how much was written")
Here's what I'd like to change:
diff --git i/include/linux/seq_buf.h w/include/linux/seq_buf.h
index 05e70ac18ddb..63d077dd8a74 100644
--- i/include/linux/seq_buf.h
+++ w/include/linux/seq_buf.h
@@ -78,7 +78,7 @@
/* How much buffer was written? */
static inline unsigned int seq_buf_used(struct seq_buf *s)
{
- return min(s->len, s->size);
+ return min(s->len, s->size - 1);
}
/**
The rationale for having that -1 is the following:
Consider a representation of a buffer where s->p holds either a pointer
to the terminating null byte (or the position where it should be written,
if not yet written), or NULL if the buffer has overflown, and s->end
holds unconditionally ARRAY_END() of the buffer.
By doing s->size-1 on overflow, we'd translate it to s->end-1 with the
pointer representation, which happens to point to the null byte (or
where it should be written), which would make this offset quite
consistent.
If we do s->size without the -1, then that offset puts us one-past-the-
last element, which isn't usable in the same places.
If you would accept a patch to add back that -1, let me know and I'll
send it, or feel free to do it yourself adding the following:
Reported-by: Alejandro Colomar <alx@kernel.org>
Suggested-by: Alejandro Colomar <alx@kernel.org>
I guess it would be better that I send a patch with a proper commit
message.
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-10-28 20:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-28 17:13 seq_buf_putc() and strings Alejandro Colomar
2026-10-28 17:30 ` Alejandro Colomar
2026-10-28 17:47 ` Steven Rostedt
2026-10-28 18:00 ` Alejandro Colomar
2026-10-28 20:59 ` Alejandro Colomar [this message]
2026-10-28 21:03 ` seq_buf_used() return value on overflow Alejandro Colomar
2026-10-28 21:30 ` seq_buf_str() silent truncation (data corruption) Alejandro Colomar
2026-10-29 1:04 ` Steven Rostedt
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=auJfBNeZGDbvMBxS@devuan \
--to=alx+linux-hardening@kernel.org \
--cc=jkosina@suse.cz \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=pmladek@suse.cz \
--cc=rostedt@goodmis.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.