linux-kernel - Re: [perf] more perf_fuzzer memory corruption

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, 29 Apr 2014 14:11:09 -0400 (EDT)
From:	Vince Weaver <vincent.weaver@...ne.edu>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Vince Weaver <vincent.weaver@...ne.edu>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [perf] more perf_fuzzer memory corruption

On Tue, 29 Apr 2014, Peter Zijlstra wrote:

> On Mon, Apr 28, 2014 at 10:21:34AM -0400, Vince Weaver wrote:
> > so it's looking more and more like this issue is with a
> > 	PERF_COUNT_SW_TASK_CLOCK
> > event.
> 
> But they don't actually use the hlist thing..

yes.

This turns out into another issue that I think is just use-after-free 
memory corruption exhibiting itself a different way.

I've documented at least 8 different types of error message that I think 
are all due to this issue.

> So this is a different problem from the hlist corruption?

Who knows.  That's why I'm trying to get this issue fixed so I can figure 
out which of the 10+ other bugs I'm tracking are the same or different.

> > This is made all the more confusing because the PERF_COUNT_SW_TASK_CLOCK 
> > events are handled by their own PMU even though it's faked up so they look 
> > like regular software events.  Is there a reason for that?
> 
> This was the easiest route when we introduced the mulitple pmu thing or
> so, its been on the todo list for a cleanup ever since :-/

It was very confusing and poorly documented, as is much of the perf_event 
files.  And yes, I know, I should do something about it rather than 
complain.

I've actually given up on source code inspection to figure out what's 
going on in kernel/events/core.c.  What I do now is write simple test
cases and do an ftrace function trace.  The results are often surprising.

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