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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.10.1404291534520.22490@vincent-weaver-1.umelst.maine.edu>
Date:	Tue, 29 Apr 2014 16:59:55 -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:

> Fair point, nope not in that case. If you can trigger this without ever
> using .inherit=1 this would exclude a lot of funny code.

I don't think inherit is being set, but I'm not actually sure.
I will have to add that to the trace_printk() and recompile/re-run



In the meantime I had a lucky crash and managed to catch a trace.

Unfortunately there's a lot of active events so it's not clear which is 
which.  I think this is going to need another round of trace generation :(

This trace can be found here:
	http://web.eece.maine.edu/~vweaver/junk/bug.out.bz2

A summary:

The troublesome memory address is allocated as part of a perf_event_open
	perf_fuzzer-4387  [001]  1802.628663: kmalloc:              (perf_event_alloc+0x5a) call_site=ffffffff8113a8fa ptr=0xffff8800a3122800 bytes_req=1272 bytes_alloc=2048 gfp_flags=GFP_KERNEL|GFP_ZERO

The event opened successfully, fd=41, it looks like it is 
PERF_COUNT_SW_EMULATION_FAULTS with attr.period=0
	perf_fuzzer-4387  [001]  1802.628677: bprint:               SYSC_perf_event_open: Opened: 1 8 0
	perf_fuzzer-4387  [001]  1802.628677: sys_exit:             NR 298 = 41

The parent forks:
	perf_fuzzer-4387  [002]  1803.571239: sys_exit:             NR 56 = 5504

The event is closed in the parent:
	perf_fuzzer-4387  [002]  1803.582345: sys_enter:            NR 3 (29, 3000, 3000, 7f7524d760a4, 7f7524d76108, 7f7524d76120)
	perf_fuzzer-4387  [002]  1803.582345: sys_exit:             NR 3 = 0

The parent kills the child:
	perf_fuzzer-4387  [003]  1803.590145: sys_enter:            NR 62 (1580, 9, 7, 7f7524d760b8, 7f7524d760b8, 7f7524d76120)

Presumably one of the many perf_swevent_del() calls in the child is us.
	perf_fuzzer-5504  [004]  1803.590277: function:             perf_swevent_del

*** The parent somehow fails to call perf_swevent_del() on CPU3? ***

The grace period expires and the memory is freed:
	ksoftirqd/4-28    [004]  1803.609802: kfree:                (free_event_rcu+0x2f) call_site=ffffffff8113177f ptr=0xffff8800a3122800

An event is deleted from swevent_hlist, but ->pprev was our free'd address:
	perf_fuzzer-4387  [003]  1803.610555: function:             perf_swevent_del

Slab corruption:
	[ 1803.610555] ------------[ cut here ]------------
	[ 1803.615419] WARNING: CPU: 3 PID: 4387 at include/linux/list.h:620 perf_swevent_del+0x6e/0x90()
	[ 1803.948487] Slab corruption (Tainted: G        W    ): kmalloc-2048 start=ffff8800a3122800, len=2048
	[ 1803.958294] 040: 6b 6b 6b 6b 6b 6b 6b 6b 88 f7 92 17 01 88 ff ff  kkkkkkkk........
--
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/