linux-kernel - Re: [PATCH ftrace/core 1/2] [BUGFIX] ftrace: Avoid panic when allocation of max

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:	Tue, 3 Jun 2014 19:50:50 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>
Cc:	linux-kernel@...r.kernel.org,
	Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Ingo Molnar <mingo@...hat.com>, yrl.pp-manager.tt@...achi.com
Subject: Re: [PATCH ftrace/core 1/2] [BUGFIX] ftrace: Avoid panic when
 allocation of max_buffer is failed

On Tue, 03 Jun 2014 13:28:03 +0900
Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com> wrote:

> When allocation of max_buffer is failed, the kernel frees tr->trace_buffer.data
> per CPU and return -ENOMEM in allocate_trace_buffers(). However,
> tracer_alloc_buffers() calling allocate_trace_buffers() also frees the data
> per CPU for -ENOMEM by allocate_trace_buffers(). Therefore, the allocation
> failure induces double free.
> 
> For the out_free_mask path in tracer_alloc_buffers(),
> global_trace.trace_buffer.data and global_trace.max_buffer.data are
> not allocated yet, so free_percpu of those are not needed.
> 
> Signed-off-by: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>
> Cc: Steven Rostedt <rostedt@...dmis.org>
> Cc: Frederic Weisbecker <fweisbec@...il.com>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: linux-kernel@...r.kernel.org
> ---
>  kernel/trace/trace.c |    4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 626dbfd..135af32 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -6671,10 +6671,6 @@ __init static int tracer_alloc_buffers(void)
>  out_free_temp_buffer:
>  	ring_buffer_free(temp_buffer);
>  out_free_cpumask:
> -	free_percpu(global_trace.trace_buffer.data);
> -#ifdef CONFIG_TRACER_MAX_TRACE
> -	free_percpu(global_trace.max_buffer.data);
> -#endif
>  	free_cpumask_var(global_trace.tracing_cpumask);
>  out_free_buffer_mask:
>  	free_cpumask_var(tracing_buffer_mask);

OK, so this is a double free on an error path at boot up. As it is
highly unlikely, I'll just add it for my 3.16 queue. It doesn't need to
go to stable.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/