From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754697AbbLDVAn (ORCPT ); Fri, 4 Dec 2015 16:00:43 -0500 Received: from mail-wm0-f50.google.com ([74.125.82.50]:34988 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753473AbbLDVAm (ORCPT ); Fri, 4 Dec 2015 16:00:42 -0500 MIME-Version: 1.0 In-Reply-To: <20151204203212.GA64517@ast-mbp.thefacebook.com> References: <20151204203212.GA64517@ast-mbp.thefacebook.com> From: Dmitry Vyukov Date: Fri, 4 Dec 2015 22:00:21 +0100 Message-ID: Subject: Re: use-after-free in __perf_install_in_context To: Alexei Starovoitov Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , LKML , syzkaller , Kostya Serebryany , Alexander Potapenko , Eric Dumazet , Sasha Levin Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 4, 2015 at 9:32 PM, Alexei Starovoitov wrote: > 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. It is a good question. I will test it.