* Re: [syzbot] [nilfs?] KASAN: slab-out-of-bounds Read in wb_writeback [not found] <000000000000fd0f2a061506cc93@google.com> @ 2024-04-02 14:38 ` syzbot 2024-04-03 9:47 ` Jan Kara 0 siblings, 1 reply; 6+ messages in thread From: syzbot @ 2024-04-02 14:38 UTC (permalink / raw) To: brauner, gregkh, jack, konishi.ryusuke, linux-fsdevel, linux-kernel, linux-nilfs, syzkaller-bugs, tj, viro syzbot has found a reproducer for the following issue on: HEAD commit: c0b832517f62 Add linux-next specific files for 20240402 git tree: linux-next console+strace: https://syzkaller.appspot.com/x/log.txt?x=14af7dd9180000 kernel config: https://syzkaller.appspot.com/x/.config?x=afcaf46d374cec8c dashboard link: https://syzkaller.appspot.com/bug?extid=7b219b86935220db6dd8 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=1729f003180000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17fa4341180000 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/0d36ec76edc7/disk-c0b83251.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/6f9bb4e37dd0/vmlinux-c0b83251.xz kernel image: https://storage.googleapis.com/syzbot-assets/2349287b14b7/bzImage-c0b83251.xz mounted in repro: https://storage.googleapis.com/syzbot-assets/9760c52a227c/mount_0.gz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+7b219b86935220db6dd8@syzkaller.appspotmail.com ================================================================== BUG: KASAN: slab-out-of-bounds in __lock_acquire+0x78/0x1fd0 kernel/locking/lockdep.c:5005 Read of size 8 at addr ffff888020485fa8 by task kworker/u8:2/35 CPU: 0 PID: 35 Comm: kworker/u8:2 Not tainted 6.9.0-rc2-next-20240402-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: writeback wb_workfn (flush-7:1) 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 __lock_acquire+0x78/0x1fd0 kernel/locking/lockdep.c:5005 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] wb_writeback+0x66f/0xd30 fs/fs-writeback.c:2160 wb_check_old_data_flush fs/fs-writeback.c:2233 [inline] wb_do_writeback fs/fs-writeback.c:2286 [inline] wb_workfn+0xba1/0x1090 fs/fs-writeback.c:2314 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:388 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK> Allocated by task 5052: 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] __do_kmalloc_node mm/slub.c:4048 [inline] __kmalloc_noprof+0x200/0x410 mm/slub.c:4061 kmalloc_noprof include/linux/slab.h:664 [inline] tomoyo_realpath_from_path+0xcf/0x5e0 security/tomoyo/realpath.c:251 tomoyo_get_realpath security/tomoyo/file.c:151 [inline] tomoyo_path_perm+0x2b7/0x740 security/tomoyo/file.c:822 security_inode_getattr+0xd8/0x130 security/security.c:2269 vfs_getattr+0x45/0x430 fs/stat.c:173 vfs_fstat fs/stat.c:198 [inline] vfs_fstatat+0xd6/0x190 fs/stat.c:300 __do_sys_newfstatat fs/stat.c:468 [inline] __se_sys_newfstatat fs/stat.c:462 [inline] __x64_sys_newfstatat+0x125/0x1b0 fs/stat.c:462 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a Freed by task 5052: 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:2180 [inline] slab_free mm/slub.c:4363 [inline] kfree+0x149/0x350 mm/slub.c:4484 tomoyo_realpath_from_path+0x5a9/0x5e0 security/tomoyo/realpath.c:286 tomoyo_get_realpath security/tomoyo/file.c:151 [inline] tomoyo_path_perm+0x2b7/0x740 security/tomoyo/file.c:822 security_inode_getattr+0xd8/0x130 security/security.c:2269 vfs_getattr+0x45/0x430 fs/stat.c:173 vfs_fstat fs/stat.c:198 [inline] vfs_fstatat+0xd6/0x190 fs/stat.c:300 __do_sys_newfstatat fs/stat.c:468 [inline] __se_sys_newfstatat fs/stat.c:462 [inline] __x64_sys_newfstatat+0x125/0x1b0 fs/stat.c:462 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a The buggy address belongs to the object at ffff888020484000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 4008 bytes to the right of allocated 4096-byte region [ffff888020484000, ffff888020485000) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20480 head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0xfff80000000040(head|node=0|zone=1|lastcpupid=0xfff) page_type: 0xffffefff(slab) raw: 00fff80000000040 ffff888015042140 dead000000000100 dead000000000122 raw: 0000000000000000 0000000000040004 00000001ffffefff 0000000000000000 head: 00fff80000000040 ffff888015042140 dead000000000100 dead000000000122 head: 0000000000000000 0000000000040004 00000001ffffefff 0000000000000000 head: 00fff80000000003 ffffea0000812001 ffffea0000812048 00000000ffffffff head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid -957297381 (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:1490 prep_new_page mm/page_alloc.c:1498 [inline] get_page_from_freelist+0x2e7e/0x2f40 mm/page_alloc.c:3454 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4712 __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:2249 allocate_slab+0x5a/0x2e0 mm/slub.c:2412 new_slab mm/slub.c:2465 [inline] ___slab_alloc+0xea8/0x1430 mm/slub.c:3599 __slab_alloc+0x58/0xa0 mm/slub.c:3684 __slab_alloc_node mm/slub.c:3737 [inline] slab_alloc_node mm/slub.c:3915 [inline] kmalloc_node_trace_noprof+0x20c/0x300 mm/slub.c:4087 kmalloc_node_noprof include/linux/slab.h:677 [inline] bdi_alloc+0x4f/0x140 mm/backing-dev.c:894 __alloc_disk_node+0xb8/0x590 block/genhd.c:1347 __blk_mq_alloc_disk+0x17d/0x260 block/blk-mq.c:4166 loop_add+0x448/0xba0 drivers/block/loop.c:2032 loop_init+0x17a/0x230 drivers/block/loop.c:2275 do_one_initcall+0x248/0x880 init/main.c:1258 do_initcall_level+0x157/0x210 init/main.c:1320 do_initcalls+0x3f/0x80 init/main.c:1336 page_owner free stack trace missing Memory state around the buggy address: ffff888020485e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888020485f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888020485f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888020486000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888020486080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== --- 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [nilfs?] KASAN: slab-out-of-bounds Read in wb_writeback 2024-04-02 14:38 ` [syzbot] [nilfs?] KASAN: slab-out-of-bounds Read in wb_writeback syzbot @ 2024-04-03 9:47 ` Jan Kara 2024-04-05 11:05 ` Christian Brauner 0 siblings, 1 reply; 6+ messages in thread From: Jan Kara @ 2024-04-03 9:47 UTC (permalink / raw) To: Kemeng Shi Cc: brauner, gregkh, jack, konishi.ryusuke, linux-fsdevel, linux-kernel, linux-nilfs, syzkaller-bugs, tj, viro On Tue 02-04-24 07:38:25, syzbot wrote: > syzbot has found a reproducer for the following issue on: > > HEAD commit: c0b832517f62 Add linux-next specific files for 20240402 > git tree: linux-next > console+strace: https://syzkaller.appspot.com/x/log.txt?x=14af7dd9180000 > kernel config: https://syzkaller.appspot.com/x/.config?x=afcaf46d374cec8c > dashboard link: https://syzkaller.appspot.com/bug?extid=7b219b86935220db6dd8 > 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=1729f003180000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17fa4341180000 > > Downloadable assets: > disk image: https://storage.googleapis.com/syzbot-assets/0d36ec76edc7/disk-c0b83251.raw.xz > vmlinux: https://storage.googleapis.com/syzbot-assets/6f9bb4e37dd0/vmlinux-c0b83251.xz > kernel image: https://storage.googleapis.com/syzbot-assets/2349287b14b7/bzImage-c0b83251.xz > mounted in repro: https://storage.googleapis.com/syzbot-assets/9760c52a227c/mount_0.gz > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > Reported-by: syzbot+7b219b86935220db6dd8@syzkaller.appspotmail.com > > ================================================================== > BUG: KASAN: slab-out-of-bounds in __lock_acquire+0x78/0x1fd0 kernel/locking/lockdep.c:5005 > Read of size 8 at addr ffff888020485fa8 by task kworker/u8:2/35 Looks like the writeback cleanups are causing some use-after-free issues. The code KASAN is complaining about is: /* * Nothing written. Wait for some inode to * become available for writeback. Otherwise * we'll just busyloop. */ trace_writeback_wait(wb, work); inode = wb_inode(wb->b_more_io.prev); >>>>> spin_lock(&inode->i_lock); <<<<<< spin_unlock(&wb->list_lock); /* This function drops i_lock... */ inode_sleep_on_writeback(inode); in wb_writeback(). Now looking at the changes indeed the commit 167d6693deb ("fs/writeback: bail out if there is no more inodes for IO and queued once") is buggy because it will result in trying to fetch 'inode' from empty b_more_io list and thus we'll corrupt memory. I think instead of modifying the condition: if (list_empty(&wb->b_more_io)) { we should do: - if (progress) { + if (progress || !queued) { spin_unlock(&wb->list_lock); continue; } Kemeng? Honza > CPU: 0 PID: 35 Comm: kworker/u8:2 Not tainted 6.9.0-rc2-next-20240402-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 > Workqueue: writeback wb_workfn (flush-7:1) > 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 > __lock_acquire+0x78/0x1fd0 kernel/locking/lockdep.c:5005 > lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 > __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] > _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 > spin_lock include/linux/spinlock.h:351 [inline] > wb_writeback+0x66f/0xd30 fs/fs-writeback.c:2160 > wb_check_old_data_flush fs/fs-writeback.c:2233 [inline] > wb_do_writeback fs/fs-writeback.c:2286 [inline] > wb_workfn+0xba1/0x1090 fs/fs-writeback.c:2314 > 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:388 > ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 > ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 > </TASK> > > Allocated by task 5052: > 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] > __do_kmalloc_node mm/slub.c:4048 [inline] > __kmalloc_noprof+0x200/0x410 mm/slub.c:4061 > kmalloc_noprof include/linux/slab.h:664 [inline] > tomoyo_realpath_from_path+0xcf/0x5e0 security/tomoyo/realpath.c:251 > tomoyo_get_realpath security/tomoyo/file.c:151 [inline] > tomoyo_path_perm+0x2b7/0x740 security/tomoyo/file.c:822 > security_inode_getattr+0xd8/0x130 security/security.c:2269 > vfs_getattr+0x45/0x430 fs/stat.c:173 > vfs_fstat fs/stat.c:198 [inline] > vfs_fstatat+0xd6/0x190 fs/stat.c:300 > __do_sys_newfstatat fs/stat.c:468 [inline] > __se_sys_newfstatat fs/stat.c:462 [inline] > __x64_sys_newfstatat+0x125/0x1b0 fs/stat.c:462 > do_syscall_64+0xfb/0x240 > entry_SYSCALL_64_after_hwframe+0x72/0x7a > > Freed by task 5052: > 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:2180 [inline] > slab_free mm/slub.c:4363 [inline] > kfree+0x149/0x350 mm/slub.c:4484 > tomoyo_realpath_from_path+0x5a9/0x5e0 security/tomoyo/realpath.c:286 > tomoyo_get_realpath security/tomoyo/file.c:151 [inline] > tomoyo_path_perm+0x2b7/0x740 security/tomoyo/file.c:822 > security_inode_getattr+0xd8/0x130 security/security.c:2269 > vfs_getattr+0x45/0x430 fs/stat.c:173 > vfs_fstat fs/stat.c:198 [inline] > vfs_fstatat+0xd6/0x190 fs/stat.c:300 > __do_sys_newfstatat fs/stat.c:468 [inline] > __se_sys_newfstatat fs/stat.c:462 [inline] > __x64_sys_newfstatat+0x125/0x1b0 fs/stat.c:462 > do_syscall_64+0xfb/0x240 > entry_SYSCALL_64_after_hwframe+0x72/0x7a > > The buggy address belongs to the object at ffff888020484000 > which belongs to the cache kmalloc-4k of size 4096 > The buggy address is located 4008 bytes to the right of > allocated 4096-byte region [ffff888020484000, ffff888020485000) > > The buggy address belongs to the physical page: > page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20480 > head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 > flags: 0xfff80000000040(head|node=0|zone=1|lastcpupid=0xfff) > page_type: 0xffffefff(slab) > raw: 00fff80000000040 ffff888015042140 dead000000000100 dead000000000122 > raw: 0000000000000000 0000000000040004 00000001ffffefff 0000000000000000 > head: 00fff80000000040 ffff888015042140 dead000000000100 dead000000000122 > head: 0000000000000000 0000000000040004 00000001ffffefff 0000000000000000 > head: 00fff80000000003 ffffea0000812001 ffffea0000812048 00000000ffffffff > head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 > page dumped because: kasan: bad access detected > page_owner tracks the page as allocated > page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 1, tgid -957297381 (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:1490 > prep_new_page mm/page_alloc.c:1498 [inline] > get_page_from_freelist+0x2e7e/0x2f40 mm/page_alloc.c:3454 > __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4712 > __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:2249 > allocate_slab+0x5a/0x2e0 mm/slub.c:2412 > new_slab mm/slub.c:2465 [inline] > ___slab_alloc+0xea8/0x1430 mm/slub.c:3599 > __slab_alloc+0x58/0xa0 mm/slub.c:3684 > __slab_alloc_node mm/slub.c:3737 [inline] > slab_alloc_node mm/slub.c:3915 [inline] > kmalloc_node_trace_noprof+0x20c/0x300 mm/slub.c:4087 > kmalloc_node_noprof include/linux/slab.h:677 [inline] > bdi_alloc+0x4f/0x140 mm/backing-dev.c:894 > __alloc_disk_node+0xb8/0x590 block/genhd.c:1347 > __blk_mq_alloc_disk+0x17d/0x260 block/blk-mq.c:4166 > loop_add+0x448/0xba0 drivers/block/loop.c:2032 > loop_init+0x17a/0x230 drivers/block/loop.c:2275 > do_one_initcall+0x248/0x880 init/main.c:1258 > do_initcall_level+0x157/0x210 init/main.c:1320 > do_initcalls+0x3f/0x80 init/main.c:1336 > page_owner free stack trace missing > > Memory state around the buggy address: > ffff888020485e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ffff888020485f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > >ffff888020485f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc > ^ > ffff888020486000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ffff888020486080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ================================================================== > > > --- > 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. > -- Jan Kara <jack@suse.com> SUSE Labs, CR ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [nilfs?] KASAN: slab-out-of-bounds Read in wb_writeback 2024-04-03 9:47 ` Jan Kara @ 2024-04-05 11:05 ` Christian Brauner 2024-04-05 13:23 ` Jan Kara 0 siblings, 1 reply; 6+ messages in thread From: Christian Brauner @ 2024-04-05 11:05 UTC (permalink / raw) To: Jan Kara Cc: Kemeng Shi, gregkh, konishi.ryusuke, linux-fsdevel, linux-kernel, linux-nilfs, syzkaller-bugs, tj, viro On Wed, Apr 03, 2024 at 11:47:17AM +0200, Jan Kara wrote: > On Tue 02-04-24 07:38:25, syzbot wrote: > > syzbot has found a reproducer for the following issue on: > > > > HEAD commit: c0b832517f62 Add linux-next specific files for 20240402 > > git tree: linux-next > > console+strace: https://syzkaller.appspot.com/x/log.txt?x=14af7dd9180000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=afcaf46d374cec8c > > dashboard link: https://syzkaller.appspot.com/bug?extid=7b219b86935220db6dd8 > > 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=1729f003180000 > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17fa4341180000 > > > > Downloadable assets: > > disk image: https://storage.googleapis.com/syzbot-assets/0d36ec76edc7/disk-c0b83251.raw.xz > > vmlinux: https://storage.googleapis.com/syzbot-assets/6f9bb4e37dd0/vmlinux-c0b83251.xz > > kernel image: https://storage.googleapis.com/syzbot-assets/2349287b14b7/bzImage-c0b83251.xz > > mounted in repro: https://storage.googleapis.com/syzbot-assets/9760c52a227c/mount_0.gz > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > Reported-by: syzbot+7b219b86935220db6dd8@syzkaller.appspotmail.com > > > > ================================================================== > > BUG: KASAN: slab-out-of-bounds in __lock_acquire+0x78/0x1fd0 kernel/locking/lockdep.c:5005 > > Read of size 8 at addr ffff888020485fa8 by task kworker/u8:2/35 > > Looks like the writeback cleanups are causing some use-after-free issues. > The code KASAN is complaining about is: > > /* > * Nothing written. Wait for some inode to > * become available for writeback. Otherwise > * we'll just busyloop. > */ > trace_writeback_wait(wb, work); > inode = wb_inode(wb->b_more_io.prev); > >>>>> spin_lock(&inode->i_lock); <<<<<< > spin_unlock(&wb->list_lock); > /* This function drops i_lock... */ > inode_sleep_on_writeback(inode); > > in wb_writeback(). Now looking at the changes indeed the commit > 167d6693deb ("fs/writeback: bail out if there is no more inodes for IO and > queued once") is buggy because it will result in trying to fetch 'inode' > from empty b_more_io list and thus we'll corrupt memory. I think instead of > modifying the condition: > > if (list_empty(&wb->b_more_io)) { > > we should do: > > - if (progress) { > + if (progress || !queued) { > spin_unlock(&wb->list_lock); > continue; > } > > Kemeng? Fwiw, I observed this on xfstest too the last few days and tracked it down to this series. Here's the splat I got in case it helps: Apr 05 00:33:06 localhost kernel: ================================================================== Apr 05 00:33:06 localhost kernel: BUG: KASAN: slab-out-of-bounds in __lock_acquire.isra.0+0x1075/0x1280 Apr 05 00:33:06 localhost kernel: Read of size 8 at addr ffff88810ed40f48 by task kworker/u128:2/305560 Apr 05 00:33:06 localhost kernel: Apr 05 00:33:06 localhost kernel: CPU: 5 PID: 305560 Comm: kworker/u128:2 Not tainted 99.9.0-rc2-gdebeafad51e2 #262 Apr 05 00:33:06 localhost kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)/Incus, BIOS unknown 2/2/2022 Apr 05 00:33:06 localhost kernel: Workqueue: writeback wb_workfn (flush-259:0) Apr 05 00:33:06 localhost kernel: Call Trace: Apr 05 00:33:06 localhost kernel: <TASK> Apr 05 00:33:06 localhost kernel: dump_stack_lvl+0x5a/0x90 Apr 05 00:33:06 localhost kernel: print_report+0xce/0x650 Apr 05 00:33:06 localhost kernel: ? __virt_addr_valid+0x217/0x320 Apr 05 00:33:06 localhost kernel: kasan_report+0xd7/0x110 Apr 05 00:33:06 localhost kernel: ? __lock_acquire.isra.0+0x1075/0x1280 Apr 05 00:33:06 localhost kernel: ? __lock_acquire.isra.0+0x1075/0x1280 Apr 05 00:33:06 localhost kernel: __lock_acquire.isra.0+0x1075/0x1280 Apr 05 00:33:06 localhost kernel: lock_acquire+0x136/0x330 Apr 05 00:33:06 localhost kernel: ? wb_writeback+0x255/0x870 Apr 05 00:33:06 localhost kernel: _raw_spin_lock+0x33/0x40 Apr 05 00:33:06 localhost kernel: ? wb_writeback+0x255/0x870 Apr 05 00:33:06 localhost kernel: wb_writeback+0x255/0x870 Apr 05 00:33:06 localhost kernel: ? __pfx_wb_writeback+0x10/0x10 Apr 05 00:33:06 localhost kernel: ? __pfx_lock_release+0x10/0x10 Apr 05 00:33:06 localhost kernel: wb_workfn+0x221/0xc80 Apr 05 00:33:06 localhost kernel: ? __pfx_wb_workfn+0x10/0x10 Apr 05 00:33:06 localhost kernel: ? lock_acquire+0x136/0x330 Apr 05 00:33:06 localhost kernel: process_one_work+0x82d/0x1790 Apr 05 00:33:06 localhost kernel: ? __pfx_process_one_work+0x10/0x10 Apr 05 00:33:06 localhost kernel: ? assign_work+0x16c/0x240 Apr 05 00:33:06 localhost kernel: worker_thread+0x724/0x1300 Apr 05 00:33:06 localhost kernel: ? __kthread_parkme+0xba/0x1f0 Apr 05 00:33:06 localhost kernel: ? __pfx_worker_thread+0x10/0x10 Apr 05 00:33:06 localhost kernel: kthread+0x2ed/0x3d0 Apr 05 00:33:06 localhost kernel: ? __pfx_kthread+0x10/0x10 Apr 05 00:33:06 localhost kernel: ret_from_fork+0x31/0x70 Apr 05 00:33:06 localhost kernel: ? __pfx_kthread+0x10/0x10 Apr 05 00:33:06 localhost kernel: ret_from_fork_asm+0x1a/0x30 Apr 05 00:33:06 localhost kernel: </TASK> Apr 05 00:33:06 localhost kernel: Apr 05 00:33:06 localhost kernel: Allocated by task 1: Apr 05 00:33:06 localhost kernel: kasan_save_stack+0x33/0x60 Apr 05 00:33:06 localhost kernel: kasan_save_track+0x14/0x30 Apr 05 00:33:06 localhost kernel: __kasan_kmalloc+0xaa/0xb0 Apr 05 00:33:06 localhost kernel: psi_cgroup_alloc+0x57/0x2b0 Apr 05 00:33:06 localhost kernel: cgroup_mkdir+0x4f8/0xfb0 Apr 05 00:33:06 localhost kernel: kernfs_iop_mkdir+0x133/0x1c0 Apr 05 00:33:06 localhost kernel: vfs_mkdir+0x3b9/0x610 Apr 05 00:33:06 localhost kernel: do_mkdirat+0x27e/0x300 Apr 05 00:33:06 localhost kernel: __x64_sys_mkdir+0x65/0x80 Apr 05 00:33:06 localhost kernel: do_syscall_64+0x64/0x190 Apr 05 00:33:06 localhost kernel: entry_SYSCALL_64_after_hwframe+0x71/0x79 Apr 05 00:33:06 localhost kernel: Apr 05 00:33:06 localhost kernel: Last potentially related work creation: Apr 05 00:33:06 localhost kernel: kasan_save_stack+0x33/0x60 Apr 05 00:33:06 localhost kernel: __kasan_record_aux_stack+0xad/0xc0 Apr 05 00:33:06 localhost kernel: insert_work+0x32/0x1f0 Apr 05 00:33:06 localhost kernel: __queue_work+0x5cb/0xcb0 Apr 05 00:33:06 localhost kernel: call_timer_fn+0x16d/0x490 Apr 05 00:33:06 localhost kernel: __run_timers+0x488/0x980 Apr 05 00:33:06 localhost kernel: run_timer_base+0xfb/0x170 Apr 05 00:33:06 localhost kernel: run_timer_softirq+0x1a/0x30 Apr 05 00:33:06 localhost kernel: __do_softirq+0x26a/0x7d2 Apr 05 00:33:06 localhost kernel: Apr 05 00:33:06 localhost kernel: Second to last potentially related work creation: Apr 05 00:33:06 localhost kernel: kasan_save_stack+0x33/0x60 Apr 05 00:33:06 localhost kernel: __kasan_record_aux_stack+0xad/0xc0 Apr 05 00:33:06 localhost kernel: insert_work+0x32/0x1f0 Apr 05 00:33:06 localhost kernel: __queue_work+0x5cb/0xcb0 Apr 05 00:33:06 localhost kernel: call_timer_fn+0x16d/0x490 Apr 05 00:33:06 localhost kernel: __run_timers+0x488/0x980 Apr 05 00:33:06 localhost kernel: timer_expire_remote+0xe6/0x150 Apr 05 00:33:06 localhost kernel: tmigr_handle_remote+0x6e2/0xe00 Apr 05 00:33:06 localhost kernel: __do_softirq+0x26a/0x7d2 Apr 05 00:33:06 localhost kernel: Apr 05 00:33:06 localhost kernel: The buggy address belongs to the object at ffff88810ed40000 which belongs to the cache kmalloc-2k of size 2048 Apr 05 00:33:06 localhost kernel: The buggy address is located 2792 bytes to the right of allocated 1120-byte region [ffff88810ed40000, ffff88810ed40460) Apr 05 00:33:06 localhost kernel: Apr 05 00:33:06 localhost kernel: The buggy address belongs to the physical page: Apr 05 00:33:06 localhost kernel: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88810ed45000 pfn:0x10ed40 Apr 05 00:33:06 localhost kernel: head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 Apr 05 00:33:06 localhost kernel: flags: 0x200000000000840(slab|head|node=0|zone=2) Apr 05 00:33:06 localhost kernel: page_type: 0xffffffff() Apr 05 00:33:06 localhost kernel: raw: 0200000000000840 ffff888100042f00 ffffea00040f1a00 dead000000000002 Apr 05 00:33:06 localhost kernel: raw: ffff88810ed45000 0000000080080006 00000001ffffffff 0000000000000000 Apr 05 00:33:06 localhost kernel: head: 0200000000000840 ffff888100042f00 ffffea00040f1a00 dead000000000002 Apr 05 00:33:06 localhost kernel: head: ffff88810ed45000 0000000080080006 00000001ffffffff 0000000000000000 Apr 05 00:33:06 localhost kernel: head: 0200000000000003 ffffea00043b5001 dead000000000122 00000000ffffffff Apr 05 00:33:06 localhost kernel: head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 Apr 05 00:33:06 localhost kernel: page dumped because: kasan: bad access detected Apr 05 00:33:06 localhost kernel: Apr 05 00:33:06 localhost kernel: Memory state around the buggy address: Apr 05 00:33:06 localhost kernel: ffff88810ed40e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Apr 05 00:33:06 localhost kernel: ffff88810ed40e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Apr 05 00:33:06 localhost kernel: >ffff88810ed40f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Apr 05 00:33:06 localhost kernel: ^ Apr 05 00:33:06 localhost kernel: ffff88810ed40f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Apr 05 00:33:06 localhost kernel: ffff88810ed41000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Apr 05 00:33:06 localhost kernel: ================================================================== Apr 05 00:33:06 localhost kernel: Disabling lock debugging due to kernel taint Apr 05 00:33:06 localhost kernel: INFO: trying to register non-static key. Apr 05 00:33:06 localhost kernel: The code is fine but needs lockdep annotation, or maybe Apr 05 00:33:06 localhost kernel: you didn't initialize this object before use? Apr 05 00:33:06 localhost kernel: turning off the locking correctness validator. Apr 05 00:33:06 localhost kernel: CPU: 5 PID: 305560 Comm: kworker/u128:2 Tainted: G B 99.9.0-rc2-gdebeafad51e2 #262 Apr 05 00:33:06 localhost kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)/Incus, BIOS unknown 2/2/2022 Apr 05 00:33:06 localhost kernel: Workqueue: writeback wb_workfn (flush-259:0) Apr 05 00:33:06 localhost kernel: Call Trace: Apr 05 00:33:06 localhost kernel: <TASK> Apr 05 00:33:06 localhost kernel: dump_stack_lvl+0x5a/0x90 Apr 05 00:33:06 localhost kernel: register_lock_class+0x11dd/0x1860 Apr 05 00:33:06 localhost kernel: ? add_taint+0x2a/0x90 Apr 05 00:33:06 localhost kernel: ? end_report+0x85/0x180 Apr 05 00:33:06 localhost kernel: ? __pfx_register_lock_class+0x10/0x10 Apr 05 00:33:06 localhost kernel: __lock_acquire.isra.0+0x7f/0x1280 Apr 05 00:33:06 localhost kernel: lock_acquire+0x136/0x330 Apr 05 00:33:06 localhost kernel: ? wb_writeback+0x255/0x870 Apr 05 00:33:06 localhost kernel: _raw_spin_lock+0x33/0x40 Apr 05 00:33:06 localhost kernel: ? wb_writeback+0x255/0x870 Apr 05 00:33:06 localhost kernel: wb_writeback+0x255/0x870 Apr 05 00:33:06 localhost kernel: ? __pfx_wb_writeback+0x10/0x10 Apr 05 00:33:06 localhost kernel: ? __pfx_lock_release+0x10/0x10 Apr 05 00:33:06 localhost kernel: wb_workfn+0x221/0xc80 Apr 05 00:33:06 localhost kernel: ? __pfx_wb_workfn+0x10/0x10 Apr 05 00:33:06 localhost kernel: ? lock_acquire+0x136/0x330 Apr 05 00:33:06 localhost kernel: process_one_work+0x82d/0x1790 Apr 05 00:33:06 localhost kernel: ? __pfx_process_one_work+0x10/0x10 Apr 05 00:33:06 localhost kernel: ? assign_work+0x16c/0x240 Apr 05 00:33:06 localhost kernel: worker_thread+0x724/0x1300 Apr 05 00:33:06 localhost kernel: ? __kthread_parkme+0xba/0x1f0 Apr 05 00:33:06 localhost kernel: ? __pfx_worker_thread+0x10/0x10 Apr 05 00:33:06 localhost kernel: kthread+0x2ed/0x3d0 Apr 05 00:33:06 localhost kernel: ? __pfx_kthread+0x10/0x10 Apr 05 00:33:06 localhost kernel: ret_from_fork+0x31/0x70 Apr 05 00:33:06 localhost kernel: ? __pfx_kthread+0x10/0x10 Apr 05 00:33:06 localhost kernel: ret_from_fork_asm+0x1a/0x30 Apr 05 00:33:06 localhost kernel: </TASK> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [nilfs?] KASAN: slab-out-of-bounds Read in wb_writeback 2024-04-05 11:05 ` Christian Brauner @ 2024-04-05 13:23 ` Jan Kara 2024-04-05 13:54 ` Christian Brauner 2024-04-07 2:05 ` Kemeng Shi 0 siblings, 2 replies; 6+ messages in thread From: Jan Kara @ 2024-04-05 13:23 UTC (permalink / raw) To: Christian Brauner Cc: Jan Kara, Kemeng Shi, gregkh, konishi.ryusuke, linux-fsdevel, linux-kernel, linux-nilfs, syzkaller-bugs, tj, viro [-- Attachment #1: Type: text/plain, Size: 3241 bytes --] On Fri 05-04-24 13:05:59, Christian Brauner wrote: > On Wed, Apr 03, 2024 at 11:47:17AM +0200, Jan Kara wrote: > > On Tue 02-04-24 07:38:25, syzbot wrote: > > > syzbot has found a reproducer for the following issue on: > > > > > > HEAD commit: c0b832517f62 Add linux-next specific files for 20240402 > > > git tree: linux-next > > > console+strace: https://syzkaller.appspot.com/x/log.txt?x=14af7dd9180000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=afcaf46d374cec8c > > > dashboard link: https://syzkaller.appspot.com/bug?extid=7b219b86935220db6dd8 > > > 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=1729f003180000 > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17fa4341180000 > > > > > > Downloadable assets: > > > disk image: https://storage.googleapis.com/syzbot-assets/0d36ec76edc7/disk-c0b83251.raw.xz > > > vmlinux: https://storage.googleapis.com/syzbot-assets/6f9bb4e37dd0/vmlinux-c0b83251.xz > > > kernel image: https://storage.googleapis.com/syzbot-assets/2349287b14b7/bzImage-c0b83251.xz > > > mounted in repro: https://storage.googleapis.com/syzbot-assets/9760c52a227c/mount_0.gz > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > Reported-by: syzbot+7b219b86935220db6dd8@syzkaller.appspotmail.com > > > > > > ================================================================== > > > BUG: KASAN: slab-out-of-bounds in __lock_acquire+0x78/0x1fd0 kernel/locking/lockdep.c:5005 > > > Read of size 8 at addr ffff888020485fa8 by task kworker/u8:2/35 > > > > Looks like the writeback cleanups are causing some use-after-free issues. > > The code KASAN is complaining about is: > > > > /* > > * Nothing written. Wait for some inode to > > * become available for writeback. Otherwise > > * we'll just busyloop. > > */ > > trace_writeback_wait(wb, work); > > inode = wb_inode(wb->b_more_io.prev); > > >>>>> spin_lock(&inode->i_lock); <<<<<< > > spin_unlock(&wb->list_lock); > > /* This function drops i_lock... */ > > inode_sleep_on_writeback(inode); > > > > in wb_writeback(). Now looking at the changes indeed the commit > > 167d6693deb ("fs/writeback: bail out if there is no more inodes for IO and > > queued once") is buggy because it will result in trying to fetch 'inode' > > from empty b_more_io list and thus we'll corrupt memory. I think instead of > > modifying the condition: > > > > if (list_empty(&wb->b_more_io)) { > > > > we should do: > > > > - if (progress) { > > + if (progress || !queued) { > > spin_unlock(&wb->list_lock); > > continue; > > } > > > > Kemeng? > > Fwiw, I observed this on xfstest too the last few days and tracked it > down to this series. Here's the splat I got in case it helps: OK, since this is apparently causing more issues and Kemeng didn't reply yet, here's a fix in the form of the patch. It has passed some basic testing. Feel free to fold it into Kemeng's patch so that we don't keep linux-next broken longer than necessary. Thanks! Honza -- Jan Kara <jack@suse.com> SUSE Labs, CR [-- Attachment #2: 0001-writeback-Fix-memory-corruption-in-writeback-code.patch --] [-- Type: text/x-patch, Size: 1848 bytes --] From cede4bc05f7a9a38f21b5943c11592fdb098b4f4 Mon Sep 17 00:00:00 2001 From: Jan Kara <jack@suse.cz> Date: Fri, 5 Apr 2024 13:57:28 +0200 Subject: [PATCH] writeback: Fix memory corruption in writeback code Commit 167d6693deb3 ("fs/writeback: bail out if there is no more inodes for IO and queued once") made the loop in wb_writeback() continue, even if we didn't have any inodes in b_more_io list when we didn't queue any inodes into b_io list yet. Conceptually this is fine however the loop in this case takes the first inode from b_more_io list and waits for writeback on it to complete. When b_more_io list is empty, this results in accesses beyond the wb->b_more_io list head corrupting struct wb_writeback and memory beyond it. Fix the problem by directly restarting the loop in this case instead of going through waiting on inode in b_more_io list. Reported-by: syzbot+7b219b86935220db6dd8@syzkaller.appspotmail.com Fixes: 167d6693deb3 ("fs/writeback: bail out if there is no more inodes for IO and queued once") Signed-off-by: Jan Kara <jack@suse.cz> --- fs/fs-writeback.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index f7ed4192d0f8..92a5b8283528 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -2137,7 +2137,7 @@ static long wb_writeback(struct bdi_writeback *wb, * mean the overall work is done. So we keep looping as long * as made some progress on cleaning pages or inodes. */ - if (progress) { + if (progress || !queued) { spin_unlock(&wb->list_lock); continue; } @@ -2145,7 +2145,7 @@ static long wb_writeback(struct bdi_writeback *wb, /* * No more inodes for IO, bail */ - if (list_empty(&wb->b_more_io) && queued) { + if (list_empty(&wb->b_more_io)) { spin_unlock(&wb->list_lock); break; } -- 2.35.3 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [syzbot] [nilfs?] KASAN: slab-out-of-bounds Read in wb_writeback 2024-04-05 13:23 ` Jan Kara @ 2024-04-05 13:54 ` Christian Brauner 2024-04-07 2:05 ` Kemeng Shi 1 sibling, 0 replies; 6+ messages in thread From: Christian Brauner @ 2024-04-05 13:54 UTC (permalink / raw) To: Jan Kara Cc: Kemeng Shi, gregkh, konishi.ryusuke, linux-fsdevel, linux-kernel, linux-nilfs, syzkaller-bugs, tj, viro On Fri, Apr 05, 2024 at 03:23:46PM +0200, Jan Kara wrote: > On Fri 05-04-24 13:05:59, Christian Brauner wrote: > > On Wed, Apr 03, 2024 at 11:47:17AM +0200, Jan Kara wrote: > > > On Tue 02-04-24 07:38:25, syzbot wrote: > > > > syzbot has found a reproducer for the following issue on: > > > > > > > > HEAD commit: c0b832517f62 Add linux-next specific files for 20240402 > > > > git tree: linux-next > > > > console+strace: https://syzkaller.appspot.com/x/log.txt?x=14af7dd9180000 > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=afcaf46d374cec8c > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=7b219b86935220db6dd8 > > > > 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=1729f003180000 > > > > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17fa4341180000 > > > > > > > > Downloadable assets: > > > > disk image: https://storage.googleapis.com/syzbot-assets/0d36ec76edc7/disk-c0b83251.raw.xz > > > > vmlinux: https://storage.googleapis.com/syzbot-assets/6f9bb4e37dd0/vmlinux-c0b83251.xz > > > > kernel image: https://storage.googleapis.com/syzbot-assets/2349287b14b7/bzImage-c0b83251.xz > > > > mounted in repro: https://storage.googleapis.com/syzbot-assets/9760c52a227c/mount_0.gz > > > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > > Reported-by: syzbot+7b219b86935220db6dd8@syzkaller.appspotmail.com > > > > > > > > ================================================================== > > > > BUG: KASAN: slab-out-of-bounds in __lock_acquire+0x78/0x1fd0 kernel/locking/lockdep.c:5005 > > > > Read of size 8 at addr ffff888020485fa8 by task kworker/u8:2/35 > > > > > > Looks like the writeback cleanups are causing some use-after-free issues. > > > The code KASAN is complaining about is: > > > > > > /* > > > * Nothing written. Wait for some inode to > > > * become available for writeback. Otherwise > > > * we'll just busyloop. > > > */ > > > trace_writeback_wait(wb, work); > > > inode = wb_inode(wb->b_more_io.prev); > > > >>>>> spin_lock(&inode->i_lock); <<<<<< > > > spin_unlock(&wb->list_lock); > > > /* This function drops i_lock... */ > > > inode_sleep_on_writeback(inode); > > > > > > in wb_writeback(). Now looking at the changes indeed the commit > > > 167d6693deb ("fs/writeback: bail out if there is no more inodes for IO and > > > queued once") is buggy because it will result in trying to fetch 'inode' > > > from empty b_more_io list and thus we'll corrupt memory. I think instead of > > > modifying the condition: > > > > > > if (list_empty(&wb->b_more_io)) { > > > > > > we should do: > > > > > > - if (progress) { > > > + if (progress || !queued) { > > > spin_unlock(&wb->list_lock); > > > continue; > > > } > > > > > > Kemeng? > > > > Fwiw, I observed this on xfstest too the last few days and tracked it > > down to this series. Here's the splat I got in case it helps: > > OK, since this is apparently causing more issues and Kemeng didn't reply > yet, here's a fix in the form of the patch. It has passed some basic > testing. Feel free to fold it into Kemeng's patch so that we don't keep > linux-next broken longer than necessary. Thanks! Thanks! Folded and I mentioned that I folded a fix from you into the commit with a link to this patch. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [syzbot] [nilfs?] KASAN: slab-out-of-bounds Read in wb_writeback 2024-04-05 13:23 ` Jan Kara 2024-04-05 13:54 ` Christian Brauner @ 2024-04-07 2:05 ` Kemeng Shi 1 sibling, 0 replies; 6+ messages in thread From: Kemeng Shi @ 2024-04-07 2:05 UTC (permalink / raw) To: Jan Kara, Christian Brauner Cc: gregkh, konishi.ryusuke, linux-fsdevel, linux-kernel, linux-nilfs, syzkaller-bugs, tj, viro on 4/5/2024 9:23 PM, Jan Kara wrote: > On Fri 05-04-24 13:05:59, Christian Brauner wrote: >> On Wed, Apr 03, 2024 at 11:47:17AM +0200, Jan Kara wrote: >>> On Tue 02-04-24 07:38:25, syzbot wrote: >>>> syzbot has found a reproducer for the following issue on: >>>> >>>> HEAD commit: c0b832517f62 Add linux-next specific files for 20240402 >>>> git tree: linux-next >>>> console+strace: https://syzkaller.appspot.com/x/log.txt?x=14af7dd9180000 >>>> kernel config: https://syzkaller.appspot.com/x/.config?x=afcaf46d374cec8c >>>> dashboard link: https://syzkaller.appspot.com/bug?extid=7b219b86935220db6dd8 >>>> 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=1729f003180000 >>>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17fa4341180000 >>>> >>>> Downloadable assets: >>>> disk image: https://storage.googleapis.com/syzbot-assets/0d36ec76edc7/disk-c0b83251.raw.xz >>>> vmlinux: https://storage.googleapis.com/syzbot-assets/6f9bb4e37dd0/vmlinux-c0b83251.xz >>>> kernel image: https://storage.googleapis.com/syzbot-assets/2349287b14b7/bzImage-c0b83251.xz >>>> mounted in repro: https://storage.googleapis.com/syzbot-assets/9760c52a227c/mount_0.gz >>>> >>>> IMPORTANT: if you fix the issue, please add the following tag to the commit: >>>> Reported-by: syzbot+7b219b86935220db6dd8@syzkaller.appspotmail.com >>>> >>>> ================================================================== >>>> BUG: KASAN: slab-out-of-bounds in __lock_acquire+0x78/0x1fd0 kernel/locking/lockdep.c:5005 >>>> Read of size 8 at addr ffff888020485fa8 by task kworker/u8:2/35 >>> >>> Looks like the writeback cleanups are causing some use-after-free issues. >>> The code KASAN is complaining about is: >>> >>> /* >>> * Nothing written. Wait for some inode to >>> * become available for writeback. Otherwise >>> * we'll just busyloop. >>> */ >>> trace_writeback_wait(wb, work); >>> inode = wb_inode(wb->b_more_io.prev); >>>>>>>> spin_lock(&inode->i_lock); <<<<<< >>> spin_unlock(&wb->list_lock); >>> /* This function drops i_lock... */ >>> inode_sleep_on_writeback(inode); >>> >>> in wb_writeback(). Now looking at the changes indeed the commit >>> 167d6693deb ("fs/writeback: bail out if there is no more inodes for IO and >>> queued once") is buggy because it will result in trying to fetch 'inode' >>> from empty b_more_io list and thus we'll corrupt memory. I think instead of >>> modifying the condition: >>> >>> if (list_empty(&wb->b_more_io)) { >>> >>> we should do: >>> >>> - if (progress) { >>> + if (progress || !queued) { >>> spin_unlock(&wb->list_lock); >>> continue; >>> } >>> >>> Kemeng? >> >> Fwiw, I observed this on xfstest too the last few days and tracked it >> down to this series. Here's the splat I got in case it helps: > > OK, since this is apparently causing more issues and Kemeng didn't reply > yet, here's a fix in the form of the patch. It has passed some basic > testing. Feel free to fold it into Kemeng's patch so that we don't keep > linux-next broken longer than necessary. Thanks! Sorry for the late reply as I was on vacation these days. Also sorry for the bug introduced. The change looks good to me. Thanks a lot for helping to fix this in time. Kemeng > > Honza > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-04-07 2:05 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <000000000000fd0f2a061506cc93@google.com>
2024-04-02 14:38 ` [syzbot] [nilfs?] KASAN: slab-out-of-bounds Read in wb_writeback syzbot
2024-04-03 9:47 ` Jan Kara
2024-04-05 11:05 ` Christian Brauner
2024-04-05 13:23 ` Jan Kara
2024-04-05 13:54 ` Christian Brauner
2024-04-07 2:05 ` Kemeng Shi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).