linux-kernel - Re: perf_fuzzer: BUG in kfree() in ftrace_graph_exit

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: <20140331124704.13c3cbcc@gandalf.local.home>
Date:	Mon, 31 Mar 2014 12:47:04 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Vince Weaver <vincent.weaver@...ne.edu>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>
Subject: Re: perf_fuzzer: BUG in kfree() in ftrace_graph_exit_task

On Mon, 31 Mar 2014 18:32:40 +0200 (CEST)
Thomas Gleixner <tglx@...utronix.de> wrote:

> On Mon, 31 Mar 2014, Vince Weaver wrote:
> > 
> > This turned up with the perf_fuzzer, haswell, 3.14.
> > 
> > I'm not sure if this is related to the other object corruption bug I am 
> > seeing.  The sympstoms are similar (BUG when dereferencing low invalid
> > kernel address) but this time the hrtimer code is not involved at all.
> > 
> > This isn't reproducible, that is if I re-run the fuzzer with the same 
> > random seed after reboot the bug doesn't trigger.
> > 
> > 
> > [ 5498.573458] BUG: unable to handle kernel NULL pointer dereference at 000000000000006c
> > [ 5498.585181] IP: [<ffffffff81189111>] kfree+0x91/0x220
> > [ 5498.593887] PGD 0 
> > [ 5498.599365] Oops: 0000 [#1] SMP 
> > [ 5498.606127] Dumping ftrace buffer:
> > [ 5498.612973]    (ftrace buffer empty)
> > [ 5498.619868] Modules linked in: nfsd auth_rpcgss  .....
> > [ 5498.720303] CPU: 1 PID: 13 Comm: ksoftirqd/1 Tainted: G        W    3.14.0+ #14
> 
> It's already tainted with W, so there was a warning before that
> crash. It would be interesting to see that as well.
> 

Agreed, as the crash points to some pretty straight forward code. If
something happened to a task, it can corrupt the task ret_stack pointer
which would cause ftrace_graph_exit_task() to crash too.

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