perf: fuzzer KASAN: global-out-of-bounds in match_token

perf: fuzzer KASAN: global-out-of-bounds in match_token

[Vince Weaver]

So got my skylake machine re-compiled with gcc-5 and got this.

Should I keep reporting these, or is everyone fuzzing now so you're all 
hitting them too?

[  911.507365] ==================================================================
[  911.514824] BUG: KASAN: global-out-of-bounds in match_token+0x268/0x310 at addr ffffffffb14ad058
[  911.523912] Read of size 8 by task perf_fuzzer/20662
[  911.528945] Address belongs to variable if_tokens+0x78/0xa0
[  911.534619] CPU: 7 PID: 20662 Comm: perf_fuzzer Tainted: G             L  4.9.0-rc5+ #12
[  911.534620] Hardware name: LENOVO 10FY0017US/SKYBAY, BIOS FWKT53A   06/06/2016
[  911.534622]  ffff8801efd2f970 ffffffffb0f17c88 ffff8801efd2fa08 ffffffffb14ad058
[  911.534624]  ffff8801efd2f9f8 ffffffffb0d0a9f3 1ffff1003dfa5f38 ffff8801efd2fc38
[  911.534627]  ffff8801f12ca100 0000000000000297 ffff8801efd2fc38 ffff8801efd2fa38
[  911.534629] Call Trace:
[  911.534633]  [<ffffffffb0f17c88>] dump_stack+0x63/0x8b
[  911.534636]  [<ffffffffb0d0a9f3>] kasan_report_error+0x493/0x4c0
[  911.534638]  [<ffffffffb0f27a43>] ? simple_strtoull+0x93/0xe0
[  911.534640]  [<ffffffffb0d0b038>] kasan_report+0x58/0x60
[  911.534642]  [<ffffffffb0f31008>] ? match_token+0x268/0x310
[  911.534644]  [<ffffffffb0d0949e>] __asan_load8+0x5e/0x70
[  911.534646]  [<ffffffffb0f31008>] match_token+0x268/0x310
[  911.534649]  [<ffffffffb0d058f8>] ? kmem_cache_alloc_node_trace+0x108/0x5a0
[  911.534651]  [<ffffffffb0f30da0>] ? match_wildcard+0x130/0x130
[  911.534653]  [<ffffffffb0cbb4b5>] ? wp_page_copy+0x6f5/0xb80
[  911.534656]  [<ffffffffb0c49668>] ? perf_event_set_addr_filter+0x1f8/0x630
[  911.534658]  [<ffffffffb0c496bb>] perf_event_set_addr_filter+0x24b/0x630
[  911.534660]  [<ffffffffb0c49470>] ? perf_pin_task_context+0xd0/0xd0
[  911.534663]  [<ffffffffb0d09976>] ? kasan_unpoison_shadow+0x36/0x50
[  911.534665]  [<ffffffffb0d09add>] ? kasan_kmalloc+0xad/0xe0
[  911.534667]  [<ffffffffb0d06a0b>] ? __kmalloc_track_caller+0x10b/0x580
[  911.534669]  [<ffffffffb0cbccd0>] ? vm_normal_page+0x130/0x130
[  911.534671]  [<ffffffffb0c9fe06>] ? strndup_user+0x46/0x70
[  911.534673]  [<ffffffffb0d097d4>] ? kasan_check_write+0x14/0x20
[  911.534675]  [<ffffffffb0c9fd8d>] ? memdup_user+0x4d/0x80
[  911.534677]  [<ffffffffb0c56a7a>] perf_ioctl+0x5fa/0x810
[  911.534680]  [<ffffffffb0c56480>] ? SYSC_perf_event_open+0x11e0/0x11e0
[  911.534682]  [<ffffffffb0cc1472>] ? handle_mm_fault+0x602/0x1c30
[  911.534684]  [<ffffffffb0d589bb>] do_vfs_ioctl+0x14b/0x920
[  911.534686]  [<ffffffffb0d58870>] ? ioctl_preallocate+0x160/0x160
[  911.534689]  [<ffffffffb0e36be3>] ? security_file_permission+0xd3/0x100
[  911.534692]  [<ffffffffb0c59af8>] ? __perf_sw_event+0x98/0xc0
[  911.534694]  [<ffffffffb0aa0639>] ? __do_page_fault+0x579/0x650
[  911.534696]  [<ffffffffb0d59209>] SyS_ioctl+0x79/0x90
[  911.534699]  [<ffffffffb13f493b>] entry_SYSCALL_64_fastpath+0x1e/0xad
[  911.534700] Memory state around the buggy address:
[  911.539563]  ffffffffb14acf00: fa fa fa fa 06 fa fa fa fa fa fa fa 06 fa fa fa
[  911.546942]  ffffffffb14acf80: fa fa fa fa 03 fa fa fa fa fa fa fa 00 00 00 00
[  911.554269] >ffffffffb14ad000: 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa
[  911.561598]                                                     ^
[  911.567800]  ffffffffb14ad080: 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa
[  911.575138]  ffffffffb14ad100: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
[  911.582492] ==================================================================

Re: perf: fuzzer KASAN: global-out-of-bounds in match_token

[Vince Weaver]

Adding Alexander Shishkin as this seems to be an issue with the address 
range filtering code.

On Thu, 17 Nov 2016, Vince Weaver wrote:

> 
> So got my skylake machine re-compiled with gcc-5 and got this.
> 
> Should I keep reporting these, or is everyone fuzzing now so you're all 
> hitting them too?
> 
> [  911.507365] ==================================================================
> [  911.514824] BUG: KASAN: global-out-of-bounds in match_token+0x268/0x310 at addr ffffffffb14ad058
> [  911.523912] Read of size 8 by task perf_fuzzer/20662
> [  911.528945] Address belongs to variable if_tokens+0x78/0xa0
> [  911.534619] CPU: 7 PID: 20662 Comm: perf_fuzzer Tainted: G             L  4.9.0-rc5+ #12
> [  911.534620] Hardware name: LENOVO 10FY0017US/SKYBAY, BIOS FWKT53A   06/06/2016
> [  911.534622]  ffff8801efd2f970 ffffffffb0f17c88 ffff8801efd2fa08 ffffffffb14ad058
> [  911.534624]  ffff8801efd2f9f8 ffffffffb0d0a9f3 1ffff1003dfa5f38 ffff8801efd2fc38
> [  911.534627]  ffff8801f12ca100 0000000000000297 ffff8801efd2fc38 ffff8801efd2fa38
> [  911.534629] Call Trace:
> [  911.534633]  [<ffffffffb0f17c88>] dump_stack+0x63/0x8b
> [  911.534636]  [<ffffffffb0d0a9f3>] kasan_report_error+0x493/0x4c0
> [  911.534638]  [<ffffffffb0f27a43>] ? simple_strtoull+0x93/0xe0
> [  911.534640]  [<ffffffffb0d0b038>] kasan_report+0x58/0x60
> [  911.534642]  [<ffffffffb0f31008>] ? match_token+0x268/0x310
> [  911.534644]  [<ffffffffb0d0949e>] __asan_load8+0x5e/0x70
> [  911.534646]  [<ffffffffb0f31008>] match_token+0x268/0x310
> [  911.534649]  [<ffffffffb0d058f8>] ? kmem_cache_alloc_node_trace+0x108/0x5a0
> [  911.534651]  [<ffffffffb0f30da0>] ? match_wildcard+0x130/0x130
> [  911.534653]  [<ffffffffb0cbb4b5>] ? wp_page_copy+0x6f5/0xb80
> [  911.534656]  [<ffffffffb0c49668>] ? perf_event_set_addr_filter+0x1f8/0x630
> [  911.534658]  [<ffffffffb0c496bb>] perf_event_set_addr_filter+0x24b/0x630
> [  911.534660]  [<ffffffffb0c49470>] ? perf_pin_task_context+0xd0/0xd0
> [  911.534663]  [<ffffffffb0d09976>] ? kasan_unpoison_shadow+0x36/0x50
> [  911.534665]  [<ffffffffb0d09add>] ? kasan_kmalloc+0xad/0xe0
> [  911.534667]  [<ffffffffb0d06a0b>] ? __kmalloc_track_caller+0x10b/0x580
> [  911.534669]  [<ffffffffb0cbccd0>] ? vm_normal_page+0x130/0x130
> [  911.534671]  [<ffffffffb0c9fe06>] ? strndup_user+0x46/0x70
> [  911.534673]  [<ffffffffb0d097d4>] ? kasan_check_write+0x14/0x20
> [  911.534675]  [<ffffffffb0c9fd8d>] ? memdup_user+0x4d/0x80
> [  911.534677]  [<ffffffffb0c56a7a>] perf_ioctl+0x5fa/0x810
> [  911.534680]  [<ffffffffb0c56480>] ? SYSC_perf_event_open+0x11e0/0x11e0
> [  911.534682]  [<ffffffffb0cc1472>] ? handle_mm_fault+0x602/0x1c30
> [  911.534684]  [<ffffffffb0d589bb>] do_vfs_ioctl+0x14b/0x920
> [  911.534686]  [<ffffffffb0d58870>] ? ioctl_preallocate+0x160/0x160
> [  911.534689]  [<ffffffffb0e36be3>] ? security_file_permission+0xd3/0x100
> [  911.534692]  [<ffffffffb0c59af8>] ? __perf_sw_event+0x98/0xc0
> [  911.534694]  [<ffffffffb0aa0639>] ? __do_page_fault+0x579/0x650
> [  911.534696]  [<ffffffffb0d59209>] SyS_ioctl+0x79/0x90
> [  911.534699]  [<ffffffffb13f493b>] entry_SYSCALL_64_fastpath+0x1e/0xad
> [  911.534700] Memory state around the buggy address:
> [  911.539563]  ffffffffb14acf00: fa fa fa fa 06 fa fa fa fa fa fa fa 06 fa fa fa
> [  911.546942]  ffffffffb14acf80: fa fa fa fa 03 fa fa fa fa fa fa fa 00 00 00 00
> [  911.554269] >ffffffffb14ad000: 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa
> [  911.561598]                                                     ^
> [  911.567800]  ffffffffb14ad080: 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa
> [  911.575138]  ffffffffb14ad100: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
> [  911.582492] ==================================================================
> 
> 
> 
> 
> 
> 
> 

Re: perf: fuzzer KASAN: global-out-of-bounds in match_token

[Vince Weaver]

On Thu, 17 Nov 2016, Vince Weaver wrote:
> > 
> > [  911.507365] ==================================================================
> > [  911.514824] BUG: KASAN: global-out-of-bounds in match_token+0x268/0x310 at addr ffffffffb14ad058
> > [  911.523912] Read of size 8 by task perf_fuzzer/20662
> > [  911.528945] Address belongs to variable if_tokens+0x78/0xa0
> > [  911.534619] CPU: 7 PID: 20662 Comm: perf_fuzzer Tainted: G             L  4.9.0-rc5+ #12
> > [  911.534620] Hardware name: LENOVO 10FY0017US/SKYBAY, BIOS FWKT53A   06/06/2016
> > [  911.534622]  ffff8801efd2f970 ffffffffb0f17c88 ffff8801efd2fa08 ffffffffb14ad058
> > [  911.534624]  ffff8801efd2f9f8 ffffffffb0d0a9f3 1ffff1003dfa5f38 ffff8801efd2fc38
> > [  911.534627]  ffff8801f12ca100 0000000000000297 ffff8801efd2fc38 ffff8801efd2fa38

OK, this one is easily reproducible and from what I can tell it is caused 
by calling

ioctl(PERF_EVENT_IOC_SET_FILTER)
where the filter trying to be set is
	(((to&733)&&common_type&605)||common_flags<386922879890793102)
the ioctl itself fails due to EINVAL

I'll see if I can come up with a working small test case.

Vince

Re: perf: fuzzer KASAN: global-out-of-bounds in match_token

[Andi Kleen]

Vince Weaver <vincent.weaver@maine.edu> writes:

Adding Alex since it seems to be related to PT code.

> So got my skylake machine re-compiled with gcc-5 and got this.
>
> Should I keep reporting these, or is everyone fuzzing now so you're all 
> hitting them too?
>
> [  911.507365] ==================================================================
> [  911.514824] BUG: KASAN: global-out-of-bounds in match_token+0x268/0x310 at addr ffffffffb14ad058
> [  911.523912] Read of size 8 by task perf_fuzzer/20662
> [  911.528945] Address belongs to variable if_tokens+0x78/0xa0
> [  911.534619] CPU: 7 PID: 20662 Comm: perf_fuzzer Tainted: G             L  4.9.0-rc5+ #12
> [  911.534620] Hardware name: LENOVO 10FY0017US/SKYBAY, BIOS FWKT53A   06/06/2016
> [  911.534622]  ffff8801efd2f970 ffffffffb0f17c88 ffff8801efd2fa08 ffffffffb14ad058
> [  911.534624]  ffff8801efd2f9f8 ffffffffb0d0a9f3 1ffff1003dfa5f38 ffff8801efd2fc38
> [  911.534627]  ffff8801f12ca100 0000000000000297 ffff8801efd2fc38 ffff8801efd2fa38
> [  911.534629] Call Trace:
> [  911.534633]  [<ffffffffb0f17c88>] dump_stack+0x63/0x8b
> [  911.534636]  [<ffffffffb0d0a9f3>] kasan_report_error+0x493/0x4c0
> [  911.534638]  [<ffffffffb0f27a43>] ? simple_strtoull+0x93/0xe0
> [  911.534640]  [<ffffffffb0d0b038>] kasan_report+0x58/0x60
> [  911.534642]  [<ffffffffb0f31008>] ? match_token+0x268/0x310
> [  911.534644]  [<ffffffffb0d0949e>] __asan_load8+0x5e/0x70
> [  911.534646]  [<ffffffffb0f31008>] match_token+0x268/0x310
> [  911.534649]  [<ffffffffb0d058f8>] ? kmem_cache_alloc_node_trace+0x108/0x5a0
> [  911.534651]  [<ffffffffb0f30da0>] ? match_wildcard+0x130/0x130
> [  911.534653]  [<ffffffffb0cbb4b5>] ? wp_page_copy+0x6f5/0xb80
> [  911.534656]  [<ffffffffb0c49668>] ? perf_event_set_addr_filter+0x1f8/0x630
> [  911.534658]  [<ffffffffb0c496bb>] perf_event_set_addr_filter+0x24b/0x630
> [  911.534660]  [<ffffffffb0c49470>] ? perf_pin_task_context+0xd0/0xd0
> [  911.534663]  [<ffffffffb0d09976>] ? kasan_unpoison_shadow+0x36/0x50
> [  911.534665]  [<ffffffffb0d09add>] ? kasan_kmalloc+0xad/0xe0
> [  911.534667]  [<ffffffffb0d06a0b>] ? __kmalloc_track_caller+0x10b/0x580
> [  911.534669]  [<ffffffffb0cbccd0>] ? vm_normal_page+0x130/0x130
> [  911.534671]  [<ffffffffb0c9fe06>] ? strndup_user+0x46/0x70
> [  911.534673]  [<ffffffffb0d097d4>] ? kasan_check_write+0x14/0x20
> [  911.534675]  [<ffffffffb0c9fd8d>] ? memdup_user+0x4d/0x80
> [  911.534677]  [<ffffffffb0c56a7a>] perf_ioctl+0x5fa/0x810
> [  911.534680]  [<ffffffffb0c56480>] ? SYSC_perf_event_open+0x11e0/0x11e0
> [  911.534682]  [<ffffffffb0cc1472>] ? handle_mm_fault+0x602/0x1c30
> [  911.534684]  [<ffffffffb0d589bb>] do_vfs_ioctl+0x14b/0x920
> [  911.534686]  [<ffffffffb0d58870>] ? ioctl_preallocate+0x160/0x160
> [  911.534689]  [<ffffffffb0e36be3>] ? security_file_permission+0xd3/0x100
> [  911.534692]  [<ffffffffb0c59af8>] ? __perf_sw_event+0x98/0xc0
> [  911.534694]  [<ffffffffb0aa0639>] ? __do_page_fault+0x579/0x650
> [  911.534696]  [<ffffffffb0d59209>] SyS_ioctl+0x79/0x90
> [  911.534699]  [<ffffffffb13f493b>] entry_SYSCALL_64_fastpath+0x1e/0xad
> [  911.534700] Memory state around the buggy address:
> [  911.539563]  ffffffffb14acf00: fa fa fa fa 06 fa fa fa fa fa fa fa 06 fa fa fa
> [  911.546942]  ffffffffb14acf80: fa fa fa fa 03 fa fa fa fa fa fa fa 00 00 00 00
> [  911.554269] >ffffffffb14ad000: 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa fa
> [  911.561598]                                                     ^
> [  911.567800]  ffffffffb14ad080: 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa
> [  911.575138]  ffffffffb14ad100: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
> [  911.582492] ==================================================================

Re: perf: fuzzer KASAN: global-out-of-bounds in match_token

[Vince Weaver]

On Thu, 17 Nov 2016, Vince Weaver wrote:

> On Thu, 17 Nov 2016, Vince Weaver wrote:
> > > 
> > > [  911.507365] ==================================================================
> > > [  911.514824] BUG: KASAN: global-out-of-bounds in match_token+0x268/0x310 at addr ffffffffb14ad058
> > > [  911.523912] Read of size 8 by task perf_fuzzer/20662
> > > [  911.528945] Address belongs to variable if_tokens+0x78/0xa0

I managed to create a short reproducer that reliably causes the issue on 
my skylake test machine.



/* simplified perf_fuzzer test case */
/* that triggers BUG: KASAN: global-out-of-bounds in match_token+0x288 */
/* on a skylake machine running Linux 4.9-rc5 */
/* by Vince Weaver <vincent.weaver _at_ maine.edu> */

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <sys/syscall.h>
#include <sys/ioctl.h>
#include <linux/perf_event.h>


int perf_event_open(struct perf_event_attr *hw_event_uptr,
	pid_t pid, int cpu, int group_fd, unsigned long flags) {

	return syscall(__NR_perf_event_open,hw_event_uptr, pid, cpu,
		group_fd, flags);
}

int main(int argc, char **argv) {

	int fd7;
	struct perf_event_attr pe7;

	char filter[]="(((to&733)&&common_type&605)||common_flags<386922879890793102)";

	memset(&pe7,0,sizeof(struct perf_event_attr));
	pe7.type=7;		/* intel_pt */
	pe7.size=72;
	pe7.config=0x200ULL;	/* bit 10 = tsc */
	pe7.read_format=PERF_FORMAT_TOTAL_TIME_ENABLED; /* 1 */
	pe7.disabled=1;
	pe7.pinned=1;
	pe7.comm_exec=1;

	fd7=perf_event_open(&pe7,
				0, /* current thread */
				0, /* Only cpu 0 */
				-1, /* group leader */
				PERF_FLAG_FD_NO_GROUP /*1*/ );

	ioctl(fd7, PERF_EVENT_IOC_SET_FILTER , &filter);

	return 0;
}

Re: perf: fuzzer KASAN: global-out-of-bounds in match_token

[Ingo Molnar]

* Vince Weaver <vincent.weaver@maine.edu> wrote:

> On Thu, 17 Nov 2016, Vince Weaver wrote:
> 
> > On Thu, 17 Nov 2016, Vince Weaver wrote:
> > > > 
> > > > [  911.507365] ==================================================================
> > > > [  911.514824] BUG: KASAN: global-out-of-bounds in match_token+0x268/0x310 at addr ffffffffb14ad058
> > > > [  911.523912] Read of size 8 by task perf_fuzzer/20662
> > > > [  911.528945] Address belongs to variable if_tokens+0x78/0xa0
> 
> I managed to create a short reproducer that reliably causes the issue on 
> my skylake test machine.

Awesome, thanks a lot Vince!

	Ingo

Re: perf: fuzzer KASAN: global-out-of-bounds in match_token

[Alexander Shishkin]

Vince Weaver <vincent.weaver@maine.edu> writes:

> On Thu, 17 Nov 2016, Vince Weaver wrote:
>
>> On Thu, 17 Nov 2016, Vince Weaver wrote:
>> > > 
>> > > [  911.507365] ==================================================================
>> > > [  911.514824] BUG: KASAN: global-out-of-bounds in match_token+0x268/0x310 at addr ffffffffb14ad058
>> > > [  911.523912] Read of size 8 by task perf_fuzzer/20662
>> > > [  911.528945] Address belongs to variable if_tokens+0x78/0xa0
>
> I managed to create a short reproducer that reliably causes the issue on 
> my skylake test machine.

Thanks a bunch, and ugh, this is embarrassing.

>From 139306c3bcf7abf49c51a8e56131aaae51222594 Mon Sep 17 00:00:00 2001
From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Date: Fri, 18 Nov 2016 13:24:55 +0200
Subject: [PATCH] perf: Fix address filter parser

The token table passed into match_token() must be null-terminated, which
it currently is not in the perf's address filter string parser, as caught
by Vince's perf_fuzzer and KASAN. It doesn't blow up otherwise because of
the alignment padding of the table to the next element in the .rodata,
which is luck.

Fixing by adding a null-terminator to the token table.

Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Fixes: 375637bc524 ("perf/core: Introduce address range filtering")
Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Cc: stable@vger.kernel.org # v4.7+
---
 kernel/events/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index c6e47e97b3..63c72dee71 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -8012,6 +8012,7 @@ static void perf_event_addr_filters_apply(struct perf_event *event)
  * if <size> is not specified, the range is treated as a single address.
  */
 enum {
+	IF_ACT_NONE = -1,
 	IF_ACT_FILTER,
 	IF_ACT_START,
 	IF_ACT_STOP,
@@ -8035,6 +8036,7 @@ static const match_table_t if_tokens = {
 	{ IF_SRC_KERNEL,	"%u/%u" },
 	{ IF_SRC_FILEADDR,	"%u@%s" },
 	{ IF_SRC_KERNELADDR,	"%u" },
+	{ IF_ACT_NONE,		NULL },
 };
 
 /*
-- 
2.10.2

Re: perf: fuzzer KASAN: global-out-of-bounds in match_token

[Vince Weaver]

On Fri, 18 Nov 2016, Alexander Shishkin wrote:

> From 139306c3bcf7abf49c51a8e56131aaae51222594 Mon Sep 17 00:00:00 2001
> From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> Date: Fri, 18 Nov 2016 13:24:55 +0200
> Subject: [PATCH] perf: Fix address filter parser
> 
> The token table passed into match_token() must be null-terminated, which
> it currently is not in the perf's address filter string parser, as caught
> by Vince's perf_fuzzer and KASAN. It doesn't blow up otherwise because of
> the alignment padding of the table to the next element in the .rodata,
> which is luck.

I can confirm that with this patch applied I no longer get the 
token-parsing KASAN messages.

This is even after I enhanced the perf_fuzzer to generate more realistic 
address-filters.

As an aside, is there any better documentation on what a "proper" address 
filter looks like?  In kernel/events/core.c it says

 * ACTION RANGE_SPEC
 * where ACTION is one of the
 *  * "filter": limit the trace to this region
 *  * "start": start tracing from this address
 *  * "stop": stop tracing at this address/region;
 * RANGE_SPEC is
 *  * for kernel addresses: <start address>[/<size>]
 *  * for object files:     <start address>[/<size>]@</path/to/object/file>

Does each action always get a range?

Are the ranges hex? decimal?  can they have a leading 0x?
Are the sizes hex? decimal?
What's the path to object file for?  What kind of object file?

Vince

[tip:perf/urgent] perf/core: Fix address filter parser

[tip-bot for Alexander Shishkin]

Commit-ID:  e96271f3ed7e702fa36dd0605c0c5b5f065af816
Gitweb:     http://git.kernel.org/tip/e96271f3ed7e702fa36dd0605c0c5b5f065af816
Author:     Alexander Shishkin <alexander.shishkin@linux.intel.com>
AuthorDate: Fri, 18 Nov 2016 13:38:43 +0200
Committer:  Ingo Molnar <mingo@kernel.org>
CommitDate: Mon, 21 Nov 2016 11:28:36 +0100

perf/core: Fix address filter parser

The token table passed into match_token() must be null-terminated, which
it currently is not in the perf's address filter string parser, as caught
by Vince's perf_fuzzer and KASAN.

It doesn't blow up otherwise because of the alignment padding of the table
to the next element in the .rodata, which is luck.

Fixing by adding a null-terminator to the token table.

Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Tested-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dvyukov@google.com
Cc: stable@vger.kernel.org # v4.7+
Fixes: 375637bc524 ("perf/core: Introduce address range filtering")
Link: http://lkml.kernel.org/r/877f81f264.fsf@ashishki-desk.ger.corp.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 kernel/events/core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index ff230bb..6ee1feb 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -8029,6 +8029,7 @@ restart:
  * if <size> is not specified, the range is treated as a single address.
  */
 enum {
+	IF_ACT_NONE = -1,
 	IF_ACT_FILTER,
 	IF_ACT_START,
 	IF_ACT_STOP,
@@ -8052,6 +8053,7 @@ static const match_table_t if_tokens = {
 	{ IF_SRC_KERNEL,	"%u/%u" },
 	{ IF_SRC_FILEADDR,	"%u@%s" },
 	{ IF_SRC_KERNELADDR,	"%u" },
+	{ IF_ACT_NONE,		NULL },
 };
 
 /*