Re: [PATCH 1/2] xfs: reset xfs_inode struct on reclaim in debug mode

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Fri, Apr 06, 2018 at 09:28:07AM -0400, Brian Foster wrote:
> On Fri, Apr 06, 2018 at 07:14:37AM +1000, Dave Chinner wrote:
> > On Thu, Apr 05, 2018 at 08:11:46AM -0400, Brian Foster wrote:
> > > A test case to reproduce a filestream/MRU use-after-free of a
> > > reclaimed inode requires bits (e.g., ip->i_mount) of the inode to be
> > > reset/reused once the inode memory is freed. This normally only
> > > occurs when a new page is cycled into the zone, however.
> > > 
> > > Perform the "one-time" inode init immediately prior to freeing
> > > inodes when in DEBUG mode. This will zero the inode, init the low
> > > level structures (locks, lists, etc.) and otherwise ensure each
> > > inode is in a purely uninitialized state while sitting in the zone
> > > as free memory.
> > 
> > Does KASAN catch this use-after-free? i.e. Given that people
> > regularly run fstests with KASAN enabled, do we need to change the
> > code for the test to trigger detection?
> > 
> 
> I had tried with page poisoning without much luck, I suspect because my
> test doesn't involve cycling pages in and out of the kmem cache. I
> hadn't tried with KASAN though. I just gave it a try with my current
> test and it looks like it detected it[1]. I guess KASAN is doing some
> kind of higher level/out-of-band tracking of slab/cache objects that
> allows this to work.
> 
> So perhaps we don't need this patch after all... I'll just document in
> the test that KASAN may be necessary to reproduce the problem.
> 
> Brian
> 
> [1] KASAN splat:
> 
> [   66.389454] BUG: KASAN: use-after-free in xfs_fstrm_free_func+0x33/0x1b0 [xfs]
> [   66.390432] Read of size 8 at addr ffff8800b02dde40 by task rmdir/1939
> [   66.391268] 
> [   66.391470] CPU: 2 PID: 1939 Comm: rmdir Not tainted 4.16.0-rc5 #111
> [   66.392228] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011

Yay!  This'll make for a nice juicy commit log. :)

Ok, so at this point this series consists of Christoph's replacement for
patch 2, and a revision of this patch to memzero/init_once?

Hm, I wonder if there's a way to tell from sysfs if kasan is enabled.

--D

> [   66.392925] Call Trace:
> [   66.393243]  dump_stack+0x85/0xc0
> [   66.393683]  print_address_description+0x65/0x270
> [   66.394190]  kasan_report+0x253/0x380
> [   66.394681]  ? xfs_fstrm_free_func+0x33/0x1b0 [xfs]
> [   66.395352]  xfs_fstrm_free_func+0x33/0x1b0 [xfs]
> [   66.395987]  xfs_remove+0x60a/0x670 [xfs]
> [   66.396567]  ? xfs_iunpin_wait+0x30/0x30 [xfs]
> [   66.397077]  ? lock_acquire+0xc0/0x220
> [   66.397463]  ? d_walk+0x1b3/0x580
> [   66.397803]  ? do_raw_spin_unlock+0x8c/0x120
> [   66.398353]  xfs_vn_unlink+0xac/0x130 [xfs]
> [   66.398915]  ? xfs_vn_rename+0x230/0x230 [xfs]
> [   66.399369]  vfs_rmdir+0x12a/0x1e0
> [   66.399736]  do_rmdir+0x258/0x2c0
> [   66.400159]  ? user_path_create+0x30/0x30
> [   66.400622]  ? up_read+0x17/0x30
> [   66.400941]  ? __do_page_fault+0x64a/0x710
> [   66.401385]  ? mark_held_locks+0x1b/0xa0
> [   66.401766]  ? mark_held_locks+0x1b/0xa0
> [   66.402181]  ? do_syscall_64+0x39/0x310
> [   66.402592]  ? SyS_mkdir+0x170/0x170
> [   66.402938]  do_syscall_64+0xf1/0x310
> [   66.403352]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> [   66.403920] RIP: 0033:0x7fad1a8f4ec7
> [   66.404327] RSP: 002b:00007fffb10c8ca8 EFLAGS: 00000246 ORIG_RAX: 0000000000000054
> [   66.405173] RAX: ffffffffffffffda RBX: 00007fffb10cab1b RCX: 00007fad1a8f4ec7
> [   66.405864] RDX: 00007fad1abc4000 RSI: 0000000000000001 RDI: 00007fffb10cab1b
> [   66.406592] RBP: 00007fffb10c8dd8 R08: 0000000000000000 R09: 0000000000000000
> [   66.407332] R10: 0000564cf39f0010 R11: 0000000000000246 R12: 0000000000000002
> [   66.408090] R13: 00007fad1abc1344 R14: 0000000000000000 R15: 0000000000000000
> [   66.408819] 
> [   66.408977] Allocated by task 1929:
> [   66.409340]  kasan_kmalloc+0xa0/0xd0
> [   66.409732]  kmem_cache_alloc+0xe8/0x2e0
> [   66.410250]  kmem_zone_alloc+0x5e/0xf0 [xfs]
> [   66.410808]  xfs_inode_alloc+0x2d/0x2b0 [xfs]
> [   66.411358]  xfs_iget+0x616/0x1740 [xfs]
> [   66.411860]  xfs_ialloc+0x18b/0xb10 [xfs]
> [   66.412423]  xfs_dir_ialloc+0x21e/0x3f0 [xfs]
> [   66.413032]  xfs_create+0x7b4/0xb60 [xfs]
> [   66.413608]  xfs_generic_create+0x303/0x3f0 [xfs]
> [   66.414127]  vfs_mkdir+0x1d2/0x2e0
> [   66.414465]  SyS_mkdir+0xda/0x170
> [   66.414790]  do_syscall_64+0xf1/0x310
> [   66.415141]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
> [   66.415636] 
> [   66.415790] Freed by task 0:
> [   66.416070]  __kasan_slab_free+0x136/0x180
> [   66.416467]  kmem_cache_free+0xc9/0x340
> [   66.416839]  rcu_process_callbacks+0x2ef/0x9c0
> [   66.417262]  __do_softirq+0x11a/0x5b9
> [   66.417654] 
> [   66.417878] The buggy address belongs to the object at ffff8800b02dde40
> [   66.417878]  which belongs to the cache xfs_inode of size 1696
> [   66.419219] The buggy address is located 0 bytes inside of
> [   66.419219]  1696-byte region [ffff8800b02dde40, ffff8800b02de4e0)
> [   66.420437] The buggy address belongs to the page:
> [   66.420948] page:ffffea0002c0b600 count:1 mapcount:0 mapping:0000000000000000 index:0x0 compound_mapcount: 0
> [   66.422024] flags: 0xfffffc0008100(slab|head)
> [   66.422466] raw: 000fffffc0008100 0000000000000000 0000000000000000 0000000180110011
> [   66.423223] raw: dead000000000100 dead000000000200 ffff8800c5207480 0000000000000000
> [   66.424013] page dumped because: kasan: bad access detected
> [   66.424602] 
> [   66.424895] Memory state around the buggy address:
> [   66.425369]  ffff8800b02ddd00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [   66.426070]  ffff8800b02ddd80: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc
> [   66.426815] >ffff8800b02dde00: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> [   66.427632]                                            ^
> [   66.428213]  ffff8800b02dde80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [   66.428989]  ffff8800b02ddf00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> [   66.429750] ==================================================================
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html