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 <sp3485@xxxxxxxxxxxx> 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 <jack@xxxxxxxx> SUSE Labs, CR
