linux-kernel - Re: [PATCH 4.20 138/352] tracing: Have trace_stack nr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 11 Feb 2019 09:49:07 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Sasha Levin <sashal@...nel.org>
Subject: Re: [PATCH 4.20 138/352] tracing: Have trace_stack nr_entries
 compare not be so subtle

On Mon, 11 Feb 2019 15:16:05 +0100
Greg Kroah-Hartman <gregkh@...uxfoundation.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@...cle.com>
> Signed-off-by: Steven Rostedt (VMware) <rostedt@...dmis.org>
> Signed-off-by: Sasha Levin <sashal@...nel.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;