Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752924AbcLKIkj (ORCPT ); Sun, 11 Dec 2016 03:40:39 -0500 Received: from mail-wm0-f50.google.com ([74.125.82.50]:36112 "EHLO mail-wm0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751798AbcLKIkh (ORCPT ); Sun, 11 Dec 2016 03:40:37 -0500 MIME-Version: 1.0 In-Reply-To: References: From: Vegard Nossum Date: Sun, 11 Dec 2016 09:40:29 +0100 Message-ID: Subject: Re: kvm: use-after-free in process_srcu To: Dmitry Vyukov Cc: Steve Rutherford , Paolo Bonzini , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , KVM list , LKML , syzkaller Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1594 Lines: 35 On 11 December 2016 at 07:46, Dmitry Vyukov wrote: > Hello, > > I am getting the following use-after-free reports while running > syzkaller fuzzer. > On commit 318c8932ddec5c1c26a4af0f3c053784841c598e (Dec 7). > Unfortunately it is not reproducible, but all reports look sane and > very similar, so I would assume that it is some hard to trigger race. > In all cases the use-after-free offset within struct kvm is 344 bytes. > This points to srcu field, which starts at 208 with size 360 (I have > some debug configs enabled). [...] > [ 376.024345] [] __fput+0x34e/0x910 fs/file_table.c:208 > [ 376.024345] [] ____fput+0x1a/0x20 fs/file_table.c:244 I've been hitting what I think is a struct file refcounting bug which causes similar symptoms as you have here (the struct file is freed while somebody still has an active reference to it). > [ 376.024345] [] task_work_run+0x1a0/0x280 > kernel/task_work.c:116 > [ 376.024345] [< inline >] exit_task_work include/linux/task_work.h:21 > [ 376.024345] [] do_exit+0x1842/0x2650 kernel/exit.c:828 > [ 376.024345] [] do_group_exit+0x14e/0x420 kernel/exit.c:932 > [ 376.024345] [] get_signal+0x663/0x1880 > kernel/signal.c:2307 > [ 376.024345] [] do_signal+0xc5/0x2190 > arch/x86/kernel/signal.c:807 Was this or any other process by any chance killed by the OOM killer? That seems to be a pattern in the crashes I've seen. If not, do you know what killed this process? Vegard