Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 11 Feb 2019 09:49:07 -0500
From:   Steven Rostedt <rostedt@goodmis.org>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        Dan Carpenter <dan.carpenter@oracle.com>,
        Sasha Levin <sashal@kernel.org>
Subject: Re: [PATCH 4.20 138/352] tracing: Have trace_stack nr_entries
 compare not be so subtle
Message-ID: <20190211094907.41712c44@gandalf.local.home>
In-Reply-To: <20190211141855.296924278@linuxfoundation.org>
References: <20190211141846.543045703@linuxfoundation.org>
        <20190211141855.296924278@linuxfoundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 11 Feb 2019 15:16:05 +0100
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:

> 4.20-stable review patch.  If anyone has any objections, please let me know.
> 

This is not a bug fix and was not meant for stable. Please do not apply.

-- Steve

> ------------------
> 
> [ Upstream commit ca16b0fbb05242f18da9d810c07d3882ffed831c ]
> 
> Dan Carpenter reviewed the trace_stack.c code and figured he found an off by
> one bug.
> 
>  "From reviewing the code, it seems possible for
>   stack_trace_max.nr_entries to be set to .max_entries and in that case we
>   would be reading one element beyond the end of the stack_dump_trace[]
>   array.  If it's not set to .max_entries then the bug doesn't affect
>   runtime."
> 
> Although it looks to be the case, it is not. Because we have:
> 
>  static unsigned long stack_dump_trace[STACK_TRACE_ENTRIES+1] =
> 	 { [0 ... (STACK_TRACE_ENTRIES)] = ULONG_MAX };
> 
>  struct stack_trace stack_trace_max = {
> 	.max_entries		= STACK_TRACE_ENTRIES - 1,
> 	.entries		= &stack_dump_trace[0],
>  };
> 
> And:
> 
> 	stack_trace_max.nr_entries = x;
> 	for (; x < i; x++)
> 		stack_dump_trace[x] = ULONG_MAX;
> 
> Even if nr_entries equals max_entries, indexing with it into the
> stack_dump_trace[] array will not overflow the array. But if it is the case,
> the second part of the conditional that tests stack_dump_trace[nr_entries]
> to ULONG_MAX will always be true.
> 
> By applying Dan's patch, it removes the subtle aspect of it and makes the if
> conditional slightly more efficient.
> 
> Link: http://lkml.kernel.org/r/20180620110758.crunhd5bfep7zuiz@kili.mountain
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>  kernel/trace/trace_stack.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
> index 2b0d1ee3241c..e2a153fc1afc 100644
> --- a/kernel/trace/trace_stack.c
> +++ b/kernel/trace/trace_stack.c
> @@ -286,7 +286,7 @@ __next(struct seq_file *m, loff_t *pos)
>  {
>  	long n = *pos - 1;
>  
> -	if (n > stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX)
> +	if (n >= stack_trace_max.nr_entries || stack_dump_trace[n] == ULONG_MAX)
>  		return NULL;
>  
>  	m->private = (void *)n;