linux-kernel - Re: perf: perf_fuzzer triggers instant reboot

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: <20140910143306.GD4783@worktop.ger.corp.intel.com>
Date:	Wed, 10 Sep 2014 16:33:06 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Vince Weaver <vincent.weaver@...ne.edu>
Cc:	Sasha Levin <sasha.levin@...cle.com>, linux-kernel@...r.kernel.org,
	Paul Mackerras <paulus@...ba.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: perf: perf_fuzzer triggers instant reboot

On Wed, Sep 10, 2014 at 10:30:31AM -0400, Vince Weaver wrote:
> On Wed, 10 Sep 2014, Sasha Levin wrote:
> 
> > On 09/10/2014 09:18 AM, Vince Weaver wrote:
> > > that's what got me looking at things again, the trinity reports.  Though I 
> > > think those involve CPU hotplugging which my fuzzer shouldn't trigger.
> > > 
> > > I do think this is the same memory corruption/reboot bug that I reported 
> > > back in February (the thread is "perf_fuzzer compiled for x32 causes 
> > > reboot" but I wasn't able to isolate the problem then either.
> > > 
> > > Somehow something is stomping over memory with a forking workload (likely 
> > > an improper free with RCU like we've seen before) but the fact that it 
> > > causes a reboot immediately makes it *really* hard to debug this.
> > 
> > Could this be http://permalink.gmane.org/gmane.linux.kernel/1779436 which
> > I saw couple days ago?
> 
> It could be.
> 
> I have about 10 open bugs with similar symptoms found with my perf_fuzzer 
> here (and a few more that are possibly the same memory corruption bug that 
> "fixes" went into the kernel but it's unclear if it actually fixed things
> or just altered the locking enough to make it harder to hit).
> 
> 	http://web.eece.maine.edu/~vweaver/projects/perf_events/fuzzer/bugs_found.html
> 
> I've been trying for months now to make progress on these but this type of 
> bug is really hard to debug.

Did we actually fix some at least? I had the idea we did get a few
sorted. But yes, this is tedious and hard going :/
--
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/