linux-kernel - NULL ptr deref in perf/filter

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

Message-ID: <CAOMGZ=E5WKap-DZjbt9CZ_jG-visgUJP7LCi3RABaoQaBUnz=g@mail.gmail.com>
Date:	Wed, 27 Jul 2016 16:15:36 +0200
From:	Vegard Nossum <vegard.nossum@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	David Carrillo-Cisneros <davidcc@...gle.com>,
	Vineet Gupta <Vineet.Gupta1@...opsys.com>,
	Kan Liang <kan.liang@...el.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: NULL ptr deref in perf/filter_match

Hi,

I'm seeing this on latest linus/master:

kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
Dumping ftrace buffer:
  (ftrace buffer empty)
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.7.0+ #50
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
task: ffff880119d05400 ti: ffff880119d38000 task.ti: ffff880119d38000
RIP: 0010:[<ffffffff81327820>]  [<ffffffff81327820>] perf_iterate_sb+0x1b0/0x6a0
RSP: 0018:ffff880119d3fc30  EFLAGS: 00010046
RAX: 0000000000000000 RBX: ffff880080af8530 RCX: 0000000000000000
RDX: 1ffff100235f3465 RSI: ffffffff8376a900 RDI: ffff880080af8730
RBP: ffff880119d3fc70 R08: 0000000000000000 R09: 0000000000000000
R10: ffff8800abbfe200 R11: 0000000000000000 R12: ffffffff8131b8e0
R13: ffff880119d3fcf0 R14: dffffc0000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88011af80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fad10e87b10 CR3: 00000000a89d5000 CR4: 00000000000006e0
DR0: 00007fad1114b000 DR1: 00007fad0f4a7000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Stack:
ffff88011af9f580 ffff880119d05400 ffff88011af9a328 ffff880119d05400
ffff880119d3fd30 0000000000000003 1ffff100233a7f9a ffff8800abbfe200
ffff880119d3fd58 ffffffff81334670 0000000041b58ab3 ffffffff83bc294e
Call Trace:
[<ffffffff81334670>] __perf_event_task_sched_out+0x2a0/0xec0
[<ffffffff813343d0>] ? perf_event_update_userpage+0x630/0x630
[<ffffffff8115f2bd>] ? finish_task_switch+0x12d/0x580
[<ffffffff8351a881>] __schedule+0x9a1/0x16c0
[<ffffffff83519ee0>] ? pci_mmcfg_check_reserved+0x110/0x110
[<ffffffff81058e37>] ? dump_trace+0x117/0x300
[<ffffffff810771a6>] ? save_stack_trace+0x26/0x50
[<ffffffff8351b86a>] schedule+0x9a/0x1c0
[<ffffffff8351b9e3>] schedule_preempt_disabled+0x13/0x20
[<ffffffff811c35fd>] cpu_startup_entry+0x1cd/0x5a0
[<ffffffff83525d7f>] ? _raw_spin_unlock_irqrestore+0x1f/0x40
[<ffffffff810a76e7>] start_secondary+0x247/0x2d0
Code: 5f ff ff ff 48 8d bb 00 02 00 00 48 89 f8 48 c1 e8 03 42 80 3c
30 00 0f 85 57 04 00 00 4c 8b bb 00 02 00 00 4c 89 f8 48 c1 e8 03 <42>
80 3c 30 00 0f 85 31 04 00 00 4d 8b 3f 49 8d 7f 40 48 89 f8
RIP  [<ffffffff81327820>] perf_iterate_sb+0x1b0/0x6a0
RSP <ffff880119d3fc30>
---[ end trace fc2135c1ac1bf1e9 ]---

That seems to be roughly:

kernel/events/core.c:145
kernel/events/core.c:547 perf_cgroup_match
kernel/events/core.c:1720 event_filter_match
kernel/events/core.c:5950 perf_iterate_sb_cpu
kernel/events/core.c:5982 perf_iterate_sb
kernel/events/core.c:6794 perf_event_switch
kernel/events/core.c:2857 __perf_event_task_sched_out

In particular, it looks to me like event->ctx is NULL.

I haven't seen this before v4.7, so I'm assuming it's new since then.
This would look the most suspicious to me if it weren't for the fact
that it claims no change in functionality:

commit aab5b71ef2b5c62323b9abe397e2db57b18e1f78
Author: Peter Zijlstra <peterz@...radead.org>
Date:   Thu May 12 17:26:46 2016 +0200

   perf/core: Rename the perf_event_aux*() APIs to perf_event_sb*(),
to separate them from AUX ring-buffer record

I don't have time to look any more into this right now, sorry.


Vegard