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]

Message-ID: <alpine.DEB.2.10.1404281017590.18996@vincent-weaver-1.umelst.maine.edu>
Date:	Mon, 28 Apr 2014 10:21:34 -0400 (EDT)
From:	Vince Weaver <vincent.weaver@...ne.edu>
To:	Vince Weaver <vincent.weaver@...ne.edu>
cc:	Peter Zijlstra <peterz@...radead.org>,
	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 Thu, 24 Apr 2014, Vince Weaver wrote:

> [ 2226.257503] WARNING: CPU: 4 PID: 0 at lib/debugobjects.c:260 debug_print_object+0x83/0xa0()
> [ 2226.266545] ODEBUG: free active (active state 0) object type: hrtimer hint: perf_swevent_hrtimer+0x0/0x140
> [ 2226.389820] Call Trace:
> [ 2226.392428]  <IRQ>  [<ffffffff8164f7b3>] dump_stack+0x45/0x56
> [ 2226.398595]  [<ffffffff810647cd>] warn_slowpath_common+0x7d/0xa0
> [ 2226.405059]  [<ffffffff8106483c>] warn_slowpath_fmt+0x4c/0x50
> [ 2226.411240]  [<ffffffff813cc9e3>] debug_print_object+0x83/0xa0
> [ 2226.417535]  [<ffffffff81139200>] ? __perf_event_overflow+0x270/0x270
> [ 2226.424463]  [<ffffffff813cde73>] debug_check_no_obj_freed+0x263/0x360
> [ 2226.431500]  [<ffffffff811316aa>] ? free_event_rcu+0x2a/0x30
> [ 2226.437579]  [<ffffffff81196fd0>] kfree+0xb0/0x560
> [ 2226.442740]  [<ffffffff810ccd46>] ? rcu_process_callbacks+0x236/0x620
> [ 2226.449658]  [<ffffffff81131680>] ? pmu_dev_release+0x10/0x10
> [ 2226.455811]  [<ffffffff811316aa>] free_event_rcu+0x2a/0x30
> [ 2226.461727]  [<ffffffff810ccdad>] rcu_process_callbacks+0x29d/0x620
> [ 2226.468440]  [<ffffffff810ccd46>] ? rcu_process_callbacks+0x236/0x620
> [ 2226.475384]  [<ffffffff81069ab5>] __do_softirq+0xf5/0x290
> [ 2226.481210]  [<ffffffff81069e9d>] irq_exit+0xad/0xc0
> [ 2226.486540]  [<ffffffff81662e35>] smp_apic_timer_interrupt+0x45/0x60
> [ 2226.493350]  [<ffffffff8166181d>] apic_timer_interrupt+0x6d/0x80
> [ 2226.499798]  <EOI>  [<ffffffff810d958e>] ? tick_nohz_idle_exit+0x12e/0x1b0
> [ 2226.507192]  [<ffffffff810aa7de>] cpu_startup_entry+0x12e/0x3d0
> [ 2226.513542]  [<ffffffff81042a43>] start_secondary+0x193/0x200
> [ 2226.519706] ---[ end trace ec55e71b02ef43b3 ]---

so it's looking more and more like this issue is with a
	PERF_COUNT_SW_TASK_CLOCK
event.

It's being deallocated in a different process than it was started (due to 
fork).

And it really looks like the problem is even though the event is free'd, 
there's still an active hrtimer associated with it somehow.

I can't seem to find *why* there's an associated hrtimer though, as the 
event as far as I can tell was created with sample_period=0 and the 
various
	perf_swevent_init_hrtimer()
calls seem to guard with is_sampling()

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?

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/