From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932732AbdKONlz (ORCPT ); Wed, 15 Nov 2017 08:41:55 -0500 Received: from mx2.suse.de ([195.135.220.15]:51876 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932408AbdKONlq (ORCPT ); Wed, 15 Nov 2017 08:41:46 -0500 Date: Wed, 15 Nov 2017 14:41:44 +0100 From: Jan Kara To: Shankara Pailoor Cc: LKML , viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org Subject: Re: KASAN: use-after-free in move_expired_inodes Message-ID: <20171115134144.GB13707@quack2.suse.cz> 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 Hi, On Tue 31-10-17 22:04:49, Shankara Pailoor wrote: > I was unable to find a reproducer but I was looking at > move_expired_inodes (fs/fs-writeback.c 1093.c) and how do you ensure > that the inode can't be freed after retrieving it from the work queue? > Any insights would be appreciated. In move_expired_inodes() we hold wb->list_lock which protects the list inode is in. fs/inode.c:evict() checks for inode being in the list and removes it from the list blocking on the wb->list_lock as well. Granted list_empty(&inode->i_io_list) is not protected by any lock so that check *could* be somewhat stale but it cannot be older than e.g. time when inode's refcount dropped to 0 at which point inode->i_io_list should be already stable. But maybe flusher is shuffling inode between lists and evict() saw some intermediate state. So far I don't see how that could happen but maybe it could - will look more into that later... Honza > On Tue, Oct 31, 2017 at 9:24 AM, Shankara Pailoor wrote: > > Hi, > > > > We got the following error: > > > > BUG: KASAN: use-after-free in move_expired_inodes+0xce6/0xdf0 > > Write of size 8 at addr ffff8800a3a36bf8 by task kworker/u8:0/5 > > > > while fuzzing with Syzkaller on 4.14-rc4 on x86_64. Included is the > > trace of the crash along with the programs running around the time of > > the crash. > > > > Programs can be found here: https://pastebin.com/RYGtNn3z > > > > Stack trace here: https://pastebin.com/SaJXWMg3 > > > > We don't have a C reproducer but we will send one if we have it. > > > > Regards, > > Shankara > -- Jan Kara SUSE Labs, CR