linux-kernel - Re: [PATCH] ftrace: Avoid double-free of dyn

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]

Message-ID: <alpine.DEB.2.00.0903241152020.22830@gandalf.stny.rr.com>
Date:	Tue, 24 Mar 2009 11:54:52 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Zhaolei <zhaolei@...fujitsu.com>
cc:	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ftrace: Avoid double-free of dyn_ftrace


On Fri, 13 Mar 2009, Zhaolei wrote:

> * From: "Ingo Molnar" <mingo@...e.hu>
> > 
> > * Zhaolei <zhaolei@...fujitsu.com> wrote:
> > 
> >> If dyn_ftrace is free before ftrace_release(), 
> >> ftrace_release() will free it again and make 
> >> ftrace_free_records wrong.
> >> 
> >> Signed-off-by: Zhao Lei <zhaolei@...fujitsu.com>
> >> ---
> >>  kernel/trace/ftrace.c |    3 ++-
> >>  1 files changed, 2 insertions(+), 1 deletions(-)
> >> 
> >> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> >> index d33d306..26c45aa 100644
> >> --- a/kernel/trace/ftrace.c
> >> +++ b/kernel/trace/ftrace.c
> >> @@ -356,7 +356,8 @@ void ftrace_release(void *start, unsigned long size)
> >>  
> >>  mutex_lock(&ftrace_lock);
> >>  do_for_each_ftrace_rec(pg, rec) {
> >> - if ((rec->ip >= s) && (rec->ip < e))
> >> + if ((rec->ip >= s) && (rec->ip < e) &&
> >> +     !(rec->flags & FTRACE_FL_FREE))
> >>  ftrace_free_rec(rec);
> > 
> > Applied to tip:tracing/ftrace, thanks!
> > 
> > I'm wondering, did you trigger this in practice (if yes, how?), 
> > or have you found it via code review?
> Hello, Ingo
> 
> It is found via code review.

Hmm, could you explain this more. I'm thinking that this scenario should 
not happen, and if it does, it should probably be a bug.

Because when we call ftrace_free_rec we change the rec->ip to point to the 
next record in the chain. Something is very wrong if rec->ip >= s && 
rec->ip < e and the record is already free.

We can add a:

	WARN_ON(rec->flags & FTRACE_FL_FREE);

in ftrace_free_rec if you are worried about this happening.

-- 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/