[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200813193818.a44ea9afc447f57d470b2def@linux-foundation.org>
Date: Thu, 13 Aug 2020 19:38:18 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Masami Hiramatsu <mhiramat@...nel.org>
Subject: Re: [PATCH] bootconfig: Fix off-by-one in
xbc_node_compose_key_after()
On Thu, 13 Aug 2020 18:30:50 -0400 Steven Rostedt <rostedt@...dmis.org> wrote:
> From: Steven Rostedt (VMware) <rostedt@...dmis.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?
Powered by blists - more mailing lists