linux-kernel - Re: perf: perf_fuzzer triggers NULL pointer dereference

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] [day] [month] [year] [list]

Message-ID: <20181109163819.GA2750@krava>
Date:   Fri, 9 Nov 2018 17:38:19 +0100
From:   Jiri Olsa <jolsa@...hat.com>
To:     Vince Weaver <vincent.weaver@...ne.edu>
Cc:     Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        torvalds@...ux-foundation.org
Subject: Re: perf: perf_fuzzer triggers NULL pointer dereference

On Thu, Nov 08, 2018 at 11:46:41AM -0500, Vince Weaver wrote:
> On Thu, 8 Nov 2018, Alexander Shishkin wrote:
> 
> > Vince Weaver <vincent.weaver@...ne.edu> writes:
> > 
> > > On Thu, 8 Nov 2018, Vince Weaver wrote:
> > >
> > >> [91760.326510] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> > >> [91760.334876] PGD 0 P4D 0 
> > >> [91760.337596] Oops: 0000 [#1] SMP PTI
> > >> [91760.341332] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G        W         4.20.0-rc1+ #119
> > >> [91760.349816] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS 01/26/2014
> > >> [91760.357723] RIP: 0010:perf_prepare_sample+0x82/0x4a0
> > >
> > > so what's the best way to do the equivelent of addr2line on something like 
> > > this, now that we aren't allowed to know the RIP anymore?
> > 
> > scripts/decode_stacktrace.sh works most of the time.
> > 
> > Sounds like BTS needs fixing up again. Thanks for looking at it though!
> 
> In case it matters, it looks like the address of the oops comes down to
> 
> 	linux.git/kernel/events/core.c:6393
> 
> 	size += data->callchain->nr;
>

nice ;-) we can actual fake cpu event to become the bts event
and relay on that EARLY callchain stuff

I can bring my server down by:
  perf record -e cpu/event=0xc4/p -g -c 1

where 0xc4 is the branch instructions events

I guess something like below could prevent it,
but haven't tested it yet, will do next week

jirka


---
diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
index b7b01d762d32..1049b547fdfe 100644
--- a/arch/x86/events/intel/ds.c
+++ b/arch/x86/events/intel/ds.c
@@ -577,6 +577,8 @@ void intel_pmu_disable_bts(void)
 	update_debugctlmsr(debugctlmsr);
 }
 
+static struct perf_callchain_entry __empty_callchain = { .nr = 0, };
+
 int intel_pmu_drain_bts_buffer(void)
 {
 	struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
@@ -612,6 +614,9 @@ int intel_pmu_drain_bts_buffer(void)
 
 	perf_sample_data_init(&data, 0, event->hw.last_period);
 
+	if (event->attr.sample_type & __PERF_SAMPLE_CALLCHAIN_EARLY)
+		data.callchain = &__empty_callchain;
+
 	/*
 	 * BTS leaks kernel addresses in branches across the cpl boundary,
 	 * such as traps or system calls, so unless the user is asking for