From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755025AbbLDUcZ (ORCPT ); Fri, 4 Dec 2015 15:32:25 -0500 Received: from mail-pf0-f169.google.com ([209.85.192.169]:36144 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752509AbbLDUcY (ORCPT ); Fri, 4 Dec 2015 15:32:24 -0500 Date: Fri, 4 Dec 2015 12:32:14 -0800 From: Alexei Starovoitov To: Dmitry Vyukov Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , LKML , syzkaller , Kostya Serebryany , Alexander Potapenko , Eric Dumazet , Sasha Levin Subject: Re: use-after-free in __perf_install_in_context Message-ID: <20151204203212.GA64517@ast-mbp.thefacebook.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 04, 2015 at 09:04:35PM +0100, Dmitry Vyukov wrote: > Hello, > > While running syzkaller fuzzer I am seeing lots of the following > use-after-free reports. Unfortunately all my numerous attempts to > reproduce them in a controlled environment failed. They pop up during > fuzzing periodically (once in several hours in a single VM), but > whenever I try to stress-replay what happened in the VM before the > report, the use-after-free does not reproduce. Can somebody > knowledgeable in perf subsystem look at the report? Maybe it is > possible to figure out what happened based purely on the report. I can > pretty reliably test any proposed fixes. > All reports look like this one. Then it is usually followed by other > reports and eventually kernel hangs or dies. What happens in the > fuzzer is essentially random syscalls with random arguments, tasks > born and die concurrently and so on. I was able to reproduce it by > restricting syscalls only to perf_event_open, perf ioctls and bpf > syscall. For the sake of trying to narrow it down: does the error disappear when you stop using bpf syscall in your fuzzing? If yes, then I could have missed some interaction between perf_event_free, kprobe free and bpf_prog_free. There was a race there before. May be there is still something else.