Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1524798 > unrolled thread
| Started by | Vince Weaver <vincent.weaver@maine.edu> |
|---|---|
| First post | 2016-11-17 21:30 +0100 |
| Last post | 2016-11-18 00:20 +0100 |
| Articles | 9 — 5 participants |
Back to article view | Back to linux.kernel
perf: fuzzer KASAN: global-out-of-bounds in match_token Vince Weaver <vincent.weaver@maine.edu> - 2016-11-17 21:30 +0100
Re: perf: fuzzer KASAN: global-out-of-bounds in match_token Vince Weaver <vincent.weaver@maine.edu> - 2016-11-17 21:40 +0100
Re: perf: fuzzer KASAN: global-out-of-bounds in match_token Vince Weaver <vincent.weaver@maine.edu> - 2016-11-17 23:20 +0100
Re: perf: fuzzer KASAN: global-out-of-bounds in match_token Vince Weaver <vincent.weaver@maine.edu> - 2016-11-18 04:00 +0100
Re: perf: fuzzer KASAN: global-out-of-bounds in match_token Ingo Molnar <mingo@kernel.org> - 2016-11-18 09:30 +0100
Re: perf: fuzzer KASAN: global-out-of-bounds in match_token Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-11-18 12:50 +0100
Re: perf: fuzzer KASAN: global-out-of-bounds in match_token Vince Weaver <vincent.weaver@maine.edu> - 2016-11-18 19:10 +0100
[tip:perf/urgent] perf/core: Fix address filter parser tip-bot for Alexander Shishkin <tipbot@zytor.com> - 2016-11-21 11:40 +0100
Re: perf: fuzzer KASAN: global-out-of-bounds in match_token Andi Kleen <andi@firstfloor.org> - 2016-11-18 00:20 +0100
| From | Vince Weaver <vincent.weaver@maine.edu> |
|---|---|
| Date | 2016-11-17 21:30 +0100 |
| Subject | perf: fuzzer KASAN: global-out-of-bounds in match_token |
| Message-ID | <sEBtM-5wM-13@gated-at.bofh.it> |
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] ==================================================================
[toc] | [next] | [standalone]
| From | Vince Weaver <vincent.weaver@maine.edu> |
|---|---|
| Date | 2016-11-17 21:40 +0100 |
| Message-ID | <sEBDs-5zX-7@gated-at.bofh.it> |
| In reply to | #1524798 |
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] ================================================================== > > > > > > >
[toc] | [prev] | [next] | [standalone]
| From | Vince Weaver <vincent.weaver@maine.edu> |
|---|---|
| Date | 2016-11-17 23:20 +0100 |
| Message-ID | <sEDce-6KN-15@gated-at.bofh.it> |
| In reply to | #1524802 |
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
[toc] | [prev] | [next] | [standalone]
| From | Vince Weaver <vincent.weaver@maine.edu> |
|---|---|
| Date | 2016-11-18 04:00 +0100 |
| Message-ID | <sEHzc-10R-1@gated-at.bofh.it> |
| In reply to | #1524845 |
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;
}
[toc] | [prev] | [next] | [standalone]
| From | Ingo Molnar <mingo@kernel.org> |
|---|---|
| Date | 2016-11-18 09:30 +0100 |
| Message-ID | <sEMIy-4Dr-27@gated-at.bofh.it> |
| In reply to | #1524981 |
* 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
[toc] | [prev] | [next] | [standalone]
| From | Alexander Shishkin <alexander.shishkin@linux.intel.com> |
|---|---|
| Date | 2016-11-18 12:50 +0100 |
| Message-ID | <sEPQ6-6yx-13@gated-at.bofh.it> |
| In reply to | #1524981 |
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
[toc] | [prev] | [next] | [standalone]
| From | Vince Weaver <vincent.weaver@maine.edu> |
|---|---|
| Date | 2016-11-18 19:10 +0100 |
| Message-ID | <sEVLP-29c-7@gated-at.bofh.it> |
| In reply to | #1525221 |
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
[toc] | [prev] | [next] | [standalone]
| From | tip-bot for Alexander Shishkin <tipbot@zytor.com> |
|---|---|
| Date | 2016-11-21 11:40 +0100 |
| Subject | [tip:perf/urgent] perf/core: Fix address filter parser |
| Message-ID | <sFUaZ-8sg-23@gated-at.bofh.it> |
| In reply to | #1525221 |
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 },
};
/*
[toc] | [prev] | [next] | [standalone]
| From | Andi Kleen <andi@firstfloor.org> |
|---|---|
| Date | 2016-11-18 00:20 +0100 |
| Message-ID | <sEE8i-7lb-13@gated-at.bofh.it> |
| In reply to | #1524798 |
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] ==================================================================
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web