From: Steven Rostedt <rostedt@goodmis.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: [PATCH] bootconfig: Fix off-by-one in xbc_node_compose_key_after()
Date: Thu, 13 Aug 2020 23:04:06 -0400 [thread overview]
Message-ID: <20200813230406.2e3b9246@oasis.local.home> (raw)
In-Reply-To: <20200813193818.a44ea9afc447f57d470b2def@linux-foundation.org>
On Thu, 13 Aug 2020 19:38:18 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 13 Aug 2020 18:30:50 -0400 Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > From: Steven Rostedt (VMware) <rostedt@goodmis.org>
> >
> > While reviewing some patches for bootconfig, I noticed the following
> > code in xbc_node_compose_key_after():
> >
> > ret = snprintf(buf, size, "%s%s", xbc_node_get_data(node),
> > depth ? "." : "");
> > if (ret < 0)
> > return ret;
> > if (ret > size) {
> > size = 0;
> > } else {
> > size -= ret;
> > buf += ret;
> > }
> >
> > But snprintf() returns the number of bytes that would be written, not
> > the number of bytes that are written (ignoring the nul terminator).
> > This means that if the number of non null bytes written were to equal
> > size, then the nul byte, which snprintf() always adds, will overwrite
> > that last byte.
> >
> > ret = snprintf(buf, 5, "hello");
> > printf("buf = '%s'\n", buf);
> > printf("ret = %d\n", ret);
> >
> > produces:
> >
> > buf = 'hell'
> > ret = 5
> >
> > The string was truncated without ret being greater than 5.
> > Test (ret >= size) for overwrite.
>
> What are the end-user visible effects of the bug? IOW, why cc:stable?
>
Hmm, looking at it at a wider view, it may not be an issue. The tools
code calls this code, and I looked to see if it was possible to corrupt
the buffer by an incorrect size. But now that I'm looking at the else
part of the section, it may not be a problem as it may act the same.
That is, ret == size will make size = 0 with the size -= ret, and we
get the same result.
OK, you can drop the patch. Thanks for the review!
Although, there's no error message if the buffer is not big enough to
hold the fields.
Masami?
-- Steve
next prev parent reply other threads:[~2020-08-14 3:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-13 22:30 Steven Rostedt
2020-08-14 2:38 ` Andrew Morton
2020-08-14 3:04 ` Steven Rostedt [this message]
2020-08-15 11:28 ` Masami Hiramatsu
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=20200813230406.2e3b9246@oasis.local.home \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®