Re: [syzbot] [ext4?] KASAN: slab-use-after-free Read in fsnotify
From: Jan Kara
Date: Thu Apr 11 2024 - 08:13:58 EST
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@xxxxxxxxxxxxxxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxxx.
>
> 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@xxxxxxxx>
SUSE Labs, CR