Message-ID: <20240411121319.adhz4ylacbv6ocuu@quack3>
Date: Thu, 11 Apr 2024 14:13:19 +0200
From: Jan Kara <jack@...e.cz>
To: syzbot <syzbot+5e3f9b2a67b45f16d4e6@...kaller.appspotmail.com>
Cc: amir73il@...il.com, jack@...e.cz, linux-ext4@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	repnop@...gle.com, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [ext4?] KASAN: slab-use-after-free Read in fsnotify

On Thu 11-04-24 01:11:20, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    6ebf211bb11d Add linux-next specific files for 20240410
> git tree:       linux-next
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=12be955d180000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=16ca158ef7e08662
> dashboard link: https://syzkaller.appspot.com/bug?extid=5e3f9b2a67b45f16d4e6
> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13c91175180000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1621af9d180000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/b050f81f73ed/disk-6ebf211b.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/412c9b9a536e/vmlinux-6ebf211b.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/016527216c47/bzImage-6ebf211b.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/75ad050c9945/mount_0.gz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+5e3f9b2a67b45f16d4e6@...kaller.appspotmail.com
> 
> Quota error (device loop0): do_check_range: Getting block 0 out of range 1-5
> EXT4-fs error (device loop0): ext4_release_dquot:6905: comm kworker/u8:4: Failed to release dquot type 1
> ==================================================================
> BUG: KASAN: slab-use-after-free in fsnotify+0x2a4/0x1f70 fs/notify/fsnotify.c:539
> Read of size 8 at addr ffff88802f1dce80 by task kworker/u8:4/62
> 
> CPU: 0 PID: 62 Comm: kworker/u8:4 Not tainted 6.9.0-rc3-next-20240410-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
> Workqueue: events_unbound quota_release_workfn
> Call Trace:
>  <TASK>
>  __dump_stack lib/dump_stack.c:88 [inline]
>  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
>  print_address_description mm/kasan/report.c:377 [inline]
>  print_report+0x169/0x550 mm/kasan/report.c:488
>  kasan_report+0x143/0x180 mm/kasan/report.c:601
>  fsnotify+0x2a4/0x1f70 fs/notify/fsnotify.c:539
>  fsnotify_sb_error include/linux/fsnotify.h:456 [inline]
>  __ext4_error+0x255/0x3b0 fs/ext4/super.c:843
>  ext4_release_dquot+0x326/0x450 fs/ext4/super.c:6903
>  quota_release_workfn+0x39f/0x650 fs/quota/dquot.c:840
>  process_one_work kernel/workqueue.c:3218 [inline]
>  process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3299
>  worker_thread+0x86d/0xd70 kernel/workqueue.c:3380
>  kthread+0x2f0/0x390 kernel/kthread.c:389
>  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
>  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
>  </TASK>

Amir, I believe this happens on umount when the filesystem calls
fsnotify_sb_error() after calling fsnotify_sb_delete(). In theory these two
calls can even run in parallel and fsnotify() can be holding
fsnotify_sb_info pointer while fsnotify_sb_delete() is freeing it so we
need to figure out some proper synchronization for that...

								Honza

> Allocated by task 5085:
>  kasan_save_stack mm/kasan/common.c:47 [inline]
>  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
>  poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
>  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
>  kasan_kmalloc include/linux/kasan.h:211 [inline]
>  kmalloc_trace_noprof+0x19c/0x2b0 mm/slub.c:4109
>  kmalloc_noprof include/linux/slab.h:660 [inline]
>  kzalloc_noprof include/linux/slab.h:775 [inline]
>  fsnotify_attach_info_to_sb fs/notify/mark.c:600 [inline]
>  fsnotify_add_mark_list fs/notify/mark.c:692 [inline]
>  fsnotify_add_mark_locked+0x3b2/0xe60 fs/notify/mark.c:777
>  fanotify_add_new_mark fs/notify/fanotify/fanotify_user.c:1267 [inline]
>  fanotify_add_mark+0xbbd/0x1330 fs/notify/fanotify/fanotify_user.c:1334
>  do_fanotify_mark+0xbcc/0xd90 fs/notify/fanotify/fanotify_user.c:1896
>  __do_sys_fanotify_mark fs/notify/fanotify/fanotify_user.c:1919 [inline]
>  __se_sys_fanotify_mark fs/notify/fanotify/fanotify_user.c:1915 [inline]
>  __x64_sys_fanotify_mark+0xb5/0xd0 fs/notify/fanotify/fanotify_user.c:1915
>  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> Freed by task 5085:
>  kasan_save_stack mm/kasan/common.c:47 [inline]
>  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
>  kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
>  poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
>  __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
>  kasan_slab_free include/linux/kasan.h:184 [inline]
>  slab_free_hook mm/slub.c:2190 [inline]
>  slab_free mm/slub.c:4393 [inline]
>  kfree+0x149/0x350 mm/slub.c:4514
>  fsnotify_sb_delete+0x686/0x6f0 fs/notify/fsnotify.c:106
>  generic_shutdown_super+0xa5/0x2d0 fs/super.c:632
>  kill_block_super+0x44/0x90 fs/super.c:1675
>  ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7323
>  deactivate_locked_super+0xc4/0x130 fs/super.c:472
>  cleanup_mnt+0x426/0x4c0 fs/namespace.c:1267
>  task_work_run+0x24f/0x310 kernel/task_work.c:180
>  exit_task_work include/linux/task_work.h:38 [inline]
>  do_exit+0xa1b/0x27e0 kernel/exit.c:878
>  do_group_exit+0x207/0x2c0 kernel/exit.c:1027
>  __do_sys_exit_group kernel/exit.c:1038 [inline]
>  __se_sys_exit_group kernel/exit.c:1036 [inline]
>  __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
>  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> The buggy address belongs to the object at ffff88802f1dce80
>  which belongs to the cache kmalloc-32 of size 32
> The buggy address is located 0 bytes inside of
>  freed 32-byte region [ffff88802f1dce80, ffff88802f1dcea0)
> 
> The buggy address belongs to the physical page:
> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2f1dc
> flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)
> page_type: 0xffffefff(slab)
> raw: 00fff80000000000 ffff888015041500 ffffea000096b540 dead000000000004
> raw: 0000000000000000 0000000080400040 00000001ffffefff 0000000000000000
> page dumped because: kasan: bad access detected
> page_owner tracks the page as allocated
> page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 1, tgid -625457465 (swapper/0), ts 1, free_ts 0
>  set_page_owner include/linux/page_owner.h:32 [inline]
>  post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1468
>  prep_new_page mm/page_alloc.c:1476 [inline]
>  get_page_from_freelist+0x2ce2/0x2d90 mm/page_alloc.c:3438
>  __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4696
>  __alloc_pages_node_noprof include/linux/gfp.h:244 [inline]
>  alloc_pages_node_noprof include/linux/gfp.h:271 [inline]
>  alloc_slab_page+0x5f/0x120 mm/slub.c:2259
>  allocate_slab+0x5a/0x2e0 mm/slub.c:2422
>  new_slab mm/slub.c:2475 [inline]
>  ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3624
>  __slab_alloc+0x58/0xa0 mm/slub.c:3714
>  __slab_alloc_node mm/slub.c:3767 [inline]
>  slab_alloc_node mm/slub.c:3945 [inline]
>  __do_kmalloc_node mm/slub.c:4077 [inline]
>  kmalloc_node_track_caller_noprof+0x286/0x440 mm/slub.c:4098
>  kstrdup+0x3a/0x80 mm/util.c:62
>  kobject_set_name_vargs+0x61/0x120 lib/kobject.c:274
>  kobject_add_varg lib/kobject.c:368 [inline]
>  kobject_init_and_add+0xde/0x190 lib/kobject.c:457
>  sysfs_slab_add+0x7a/0x290 mm/slub.c:6877
>  slab_sysfs_init+0x66/0x170 mm/slub.c:6961
>  do_one_initcall+0x248/0x880 init/main.c:1263
>  do_initcall_level+0x157/0x210 init/main.c:1325
>  do_initcalls+0x3f/0x80 init/main.c:1341
> page_owner free stack trace missing
> 
> Memory state around the buggy address:
>  ffff88802f1dcd80: 00 00 05 fc fc fc fc fc 00 00 00 00 fc fc fc fc
>  ffff88802f1dce00: 00 00 00 06 fc fc fc fc fa fb fb fb fc fc fc fc
> >ffff88802f1dce80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
>                    ^
>  ffff88802f1dcf00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
>  ffff88802f1dcf80: fa fb fb fb fc fc fc fc 00 00 00 fc fc fc fc fc
> ==================================================================
> 
> 
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@...glegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> 
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
> 
> If you want syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
> 
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
> 
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
> 
> If you want to undo deduplication, reply with:
> #syz undup
> 
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists