* KCSAN: data-race in __fat_write_inode / fat12_ent_get @ 2020-04-03 12:35 syzbot 2020-04-03 13:36 ` OGAWA Hirofumi 0 siblings, 1 reply; 6+ messages in thread From: syzbot @ 2020-04-03 12:35 UTC (permalink / raw) To: elver, hirofumi, linux-kernel, syzkaller-bugs Hello, syzbot found the following crash on: HEAD commit: 40959e34 kcsan: Avoid blocking producers in prepare_report() git tree: https://github.com/google/ktsan.git kcsan console output: https://syzkaller.appspot.com/x/log.txt?x=1201d5a3e00000 kernel config: https://syzkaller.appspot.com/x/.config?x=1ab2c758651b11f6 dashboard link: https://syzkaller.appspot.com/bug?extid=6f1624f937d9d6911e2d compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+6f1624f937d9d6911e2d@syzkaller.appspotmail.com FAT-fs (loop1): error, clusters badly computed (876 != 875) FAT-fs (loop1): error, clusters badly computed (877 != 876) FAT-fs (loop1): error, clusters badly computed (878 != 877) ================================================================== BUG: KCSAN: data-race in __fat_write_inode / fat12_ent_get write to 0xffff8881015f423c of 4 bytes by task 9966 on cpu 1: __fat_write_inode+0x246/0x510 fs/fat/inode.c:877 fat_write_inode+0x67/0xe0 fs/fat/inode.c:909 write_inode fs/fs-writeback.c:1312 [inline] __writeback_single_inode+0x722/0x910 fs/fs-writeback.c:1511 writeback_single_inode+0x219/0x2f0 fs/fs-writeback.c:1565 sync_inode fs/fs-writeback.c:2602 [inline] sync_inode_metadata+0x75/0xa0 fs/fs-writeback.c:2622 __generic_file_fsync+0x117/0x180 fs/libfs.c:1081 fat_file_fsync+0x54/0x120 fs/fat/file.c:190 vfs_fsync_range+0x7c/0x150 fs/sync.c:197 generic_write_sync include/linux/fs.h:2867 [inline] generic_file_write_iter+0x31c/0x38e mm/filemap.c:3452 call_write_iter include/linux/fs.h:1901 [inline] do_iter_readv_writev+0x4a7/0x5d0 fs/read_write.c:693 do_iter_write fs/read_write.c:998 [inline] do_iter_write+0x137/0x3a0 fs/read_write.c:979 vfs_iter_write+0x56/0x80 fs/read_write.c:1039 iter_file_splice_write+0x530/0x830 fs/splice.c:760 do_splice_from fs/splice.c:863 [inline] direct_splice_actor+0x97/0xb0 fs/splice.c:1037 splice_direct_to_actor+0x22f/0x540 fs/splice.c:992 do_splice_direct+0x152/0x1d0 fs/splice.c:1080 do_sendfile+0x396/0x810 fs/read_write.c:1520 __do_sys_sendfile64 fs/read_write.c:1575 [inline] __se_sys_sendfile64 fs/read_write.c:1567 [inline] __x64_sys_sendfile64+0xb8/0x140 fs/read_write.c:1567 do_syscall_64+0xc7/0x390 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x44/0xa9 read to 0xffff8881015f423d of 1 bytes by task 9960 on cpu 0: fat12_ent_get+0x5e/0x120 fs/fat/fatent.c:125 fat_ent_read+0x3de/0x560 fs/fat/fatent.c:370 fat_get_cluster+0x52b/0x920 fs/fat/cache.c:266 fat_bmap_cluster fs/fat/cache.c:299 [inline] fat_get_mapped_cluster+0x105/0x230 fs/fat/cache.c:320 fat_bmap+0x146/0x28e fs/fat/cache.c:384 __fat_get_block fs/fat/inode.c:165 [inline] fat_get_block+0x244/0x4f0 fs/fat/inode.c:190 __block_write_begin_int+0x306/0xf80 fs/buffer.c:2008 __block_write_begin fs/buffer.c:2058 [inline] block_write_begin+0x76/0x160 fs/buffer.c:2117 cont_write_begin+0x3bd/0x660 fs/buffer.c:2466 fat_write_begin+0x69/0xc0 fs/fat/inode.c:236 pagecache_write_begin+0x67/0x90 mm/filemap.c:3106 cont_expand_zero fs/buffer.c:2393 [inline] cont_write_begin+0x176/0x660 fs/buffer.c:2456 fat_write_begin+0x69/0xc0 fs/fat/inode.c:236 generic_perform_write+0x13a/0x320 mm/filemap.c:3287 __generic_file_write_iter+0x240/0x370 mm/filemap.c:3416 generic_file_write_iter+0x294/0x38e mm/filemap.c:3448 call_write_iter include/linux/fs.h:1901 [inline] new_sync_write+0x303/0x400 fs/read_write.c:483 __vfs_write+0x9e/0xb0 fs/read_write.c:496 vfs_write fs/read_write.c:558 [inline] vfs_write+0x189/0x380 fs/read_write.c:542 ksys_write+0xc5/0x1a0 fs/read_write.c:611 __do_sys_write fs/read_write.c:623 [inline] __se_sys_write fs/read_write.c:620 [inline] __x64_sys_write+0x49/0x60 fs/read_write.c:620 do_syscall_64+0xc7/0x390 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 9960 Comm: syz-executor.1 Not tainted 5.6.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 ================================================================== --- This bug 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@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: KCSAN: data-race in __fat_write_inode / fat12_ent_get 2020-04-03 12:35 KCSAN: data-race in __fat_write_inode / fat12_ent_get syzbot @ 2020-04-03 13:36 ` OGAWA Hirofumi 2020-04-03 16:36 ` Dmitry Vyukov 0 siblings, 1 reply; 6+ messages in thread From: OGAWA Hirofumi @ 2020-04-03 13:36 UTC (permalink / raw) To: syzbot; +Cc: elver, linux-kernel, syzkaller-bugs syzbot <syzbot+6f1624f937d9d6911e2d@syzkaller.appspotmail.com> writes: > syzbot found the following crash on: > > HEAD commit: 40959e34 kcsan: Avoid blocking producers in prepare_report() > git tree: https://github.com/google/ktsan.git kcsan > console output: https://syzkaller.appspot.com/x/log.txt?x=1201d5a3e00000 > kernel config: https://syzkaller.appspot.com/x/.config?x=1ab2c758651b11f6 > dashboard link: https://syzkaller.appspot.com/bug?extid=6f1624f937d9d6911e2d > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > Unfortunately, I don't have any reproducer for this crash yet. > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+6f1624f937d9d6911e2d@syzkaller.appspotmail.com > > FAT-fs (loop1): error, clusters badly computed (876 != 875) > FAT-fs (loop1): error, clusters badly computed (877 != 876) > FAT-fs (loop1): error, clusters badly computed (878 != 877) Hm, looks like the race between a directory entry vs a FAT entry. This bug was happened with the corrupted image? Or the image passes the check of dosfsck? If the corrupted image, it may be hard to prevent the all races. Well, anyway, the corrupted image of the report will help to detect this corruption. Thanks. > ================================================================== > BUG: KCSAN: data-race in __fat_write_inode / fat12_ent_get > > write to 0xffff8881015f423c of 4 bytes by task 9966 on cpu 1: > __fat_write_inode+0x246/0x510 fs/fat/inode.c:877 > fat_write_inode+0x67/0xe0 fs/fat/inode.c:909 > write_inode fs/fs-writeback.c:1312 [inline] > __writeback_single_inode+0x722/0x910 fs/fs-writeback.c:1511 > writeback_single_inode+0x219/0x2f0 fs/fs-writeback.c:1565 > sync_inode fs/fs-writeback.c:2602 [inline] > sync_inode_metadata+0x75/0xa0 fs/fs-writeback.c:2622 > __generic_file_fsync+0x117/0x180 fs/libfs.c:1081 > fat_file_fsync+0x54/0x120 fs/fat/file.c:190 > vfs_fsync_range+0x7c/0x150 fs/sync.c:197 > generic_write_sync include/linux/fs.h:2867 [inline] > generic_file_write_iter+0x31c/0x38e mm/filemap.c:3452 > call_write_iter include/linux/fs.h:1901 [inline] > do_iter_readv_writev+0x4a7/0x5d0 fs/read_write.c:693 > do_iter_write fs/read_write.c:998 [inline] > do_iter_write+0x137/0x3a0 fs/read_write.c:979 > vfs_iter_write+0x56/0x80 fs/read_write.c:1039 > iter_file_splice_write+0x530/0x830 fs/splice.c:760 > do_splice_from fs/splice.c:863 [inline] > direct_splice_actor+0x97/0xb0 fs/splice.c:1037 > splice_direct_to_actor+0x22f/0x540 fs/splice.c:992 > do_splice_direct+0x152/0x1d0 fs/splice.c:1080 > do_sendfile+0x396/0x810 fs/read_write.c:1520 > __do_sys_sendfile64 fs/read_write.c:1575 [inline] > __se_sys_sendfile64 fs/read_write.c:1567 [inline] > __x64_sys_sendfile64+0xb8/0x140 fs/read_write.c:1567 > do_syscall_64+0xc7/0x390 arch/x86/entry/common.c:294 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > read to 0xffff8881015f423d of 1 bytes by task 9960 on cpu 0: > fat12_ent_get+0x5e/0x120 fs/fat/fatent.c:125 > fat_ent_read+0x3de/0x560 fs/fat/fatent.c:370 > fat_get_cluster+0x52b/0x920 fs/fat/cache.c:266 > fat_bmap_cluster fs/fat/cache.c:299 [inline] > fat_get_mapped_cluster+0x105/0x230 fs/fat/cache.c:320 > fat_bmap+0x146/0x28e fs/fat/cache.c:384 > __fat_get_block fs/fat/inode.c:165 [inline] > fat_get_block+0x244/0x4f0 fs/fat/inode.c:190 > __block_write_begin_int+0x306/0xf80 fs/buffer.c:2008 > __block_write_begin fs/buffer.c:2058 [inline] > block_write_begin+0x76/0x160 fs/buffer.c:2117 > cont_write_begin+0x3bd/0x660 fs/buffer.c:2466 > fat_write_begin+0x69/0xc0 fs/fat/inode.c:236 > pagecache_write_begin+0x67/0x90 mm/filemap.c:3106 > cont_expand_zero fs/buffer.c:2393 [inline] > cont_write_begin+0x176/0x660 fs/buffer.c:2456 > fat_write_begin+0x69/0xc0 fs/fat/inode.c:236 > generic_perform_write+0x13a/0x320 mm/filemap.c:3287 > __generic_file_write_iter+0x240/0x370 mm/filemap.c:3416 > generic_file_write_iter+0x294/0x38e mm/filemap.c:3448 > call_write_iter include/linux/fs.h:1901 [inline] > new_sync_write+0x303/0x400 fs/read_write.c:483 > __vfs_write+0x9e/0xb0 fs/read_write.c:496 > vfs_write fs/read_write.c:558 [inline] > vfs_write+0x189/0x380 fs/read_write.c:542 > ksys_write+0xc5/0x1a0 fs/read_write.c:611 > __do_sys_write fs/read_write.c:623 [inline] > __se_sys_write fs/read_write.c:620 [inline] > __x64_sys_write+0x49/0x60 fs/read_write.c:620 > do_syscall_64+0xc7/0x390 arch/x86/entry/common.c:294 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > Reported by Kernel Concurrency Sanitizer on: > CPU: 0 PID: 9960 Comm: syz-executor.1 Not tainted 5.6.0-rc1-syzkaller #0 > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > ================================================================== > > > --- > This bug 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@googlegroups.com. > > syzbot will keep track of this bug report. See: > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. -- OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: KCSAN: data-race in __fat_write_inode / fat12_ent_get 2020-04-03 13:36 ` OGAWA Hirofumi @ 2020-04-03 16:36 ` Dmitry Vyukov 2020-04-04 6:14 ` OGAWA Hirofumi 0 siblings, 1 reply; 6+ messages in thread From: Dmitry Vyukov @ 2020-04-03 16:36 UTC (permalink / raw) To: OGAWA Hirofumi; +Cc: syzbot, Marco Elver, LKML, syzkaller-bugs On Fri, Apr 3, 2020 at 3:36 PM OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote: > > syzbot <syzbot+6f1624f937d9d6911e2d@syzkaller.appspotmail.com> writes: > > > syzbot found the following crash on: > > > > HEAD commit: 40959e34 kcsan: Avoid blocking producers in prepare_report() > > git tree: https://github.com/google/ktsan.git kcsan > > console output: https://syzkaller.appspot.com/x/log.txt?x=1201d5a3e00000 > > kernel config: https://syzkaller.appspot.com/x/.config?x=1ab2c758651b11f6 > > dashboard link: https://syzkaller.appspot.com/bug?extid=6f1624f937d9d6911e2d > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > Reported-by: syzbot+6f1624f937d9d6911e2d@syzkaller.appspotmail.com > > > > FAT-fs (loop1): error, clusters badly computed (876 != 875) > > FAT-fs (loop1): error, clusters badly computed (877 != 876) > > FAT-fs (loop1): error, clusters badly computed (878 != 877) > > Hm, looks like the race between a directory entry vs a FAT entry. This > bug was happened with the corrupted image? Or the image passes the check > of dosfsck? > > If the corrupted image, it may be hard to prevent the all races. Well, > anyway, the corrupted image of the report will help to detect this > corruption. Hi OGAWA, From the log, it's this program. My bet on a corrupted image. syzkaller does not have format descriptions for fat, so it's just random bytes. 03:07:45 executing program 1: syz_mount_image$vfat(&(0x7f0000000080)='vfat\x00', &(0x7f00000002c0)='./file0\x00', 0xfffffffffffff57a, 0x1, &(0x7f0000000140)=[{&(0x7f0000000040)="eb3c906d6b66732e66617400020401ed01000270fff8", 0x16}], 0x0, 0x0) r0 = open(&(0x7f0000000180)='./file0\x00', 0x0, 0x0) fchdir(r0) r1 = open(&(0x7f00000000c0)='./file0\x00', 0x14107e, 0x0) write$binfmt_elf32(r1, &(0x7f0000000cc0)=ANY=[@ANYBLOB="7f454c460000000000000000000000000000000000000000000000003400000020000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e997eba191fdbf47fe0c67ef95c198d2000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000ff0f00000000000000000000000000000000000000000000aeb2ca6a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f4ffffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e3ffffff00010400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000be0500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000339300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f4ffffffffffffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000fcffffffffffffff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000000546fde79d700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e90f"], 0x801) r2 = socket$inet6(0xa, 0x2, 0x0) r3 = dup(r2) r4 = creat(&(0x7f0000000240)='./bus\x00', 0x0) lseek(r4, 0x7ffffc, 0x0) write$binfmt_elf64(r4, &(0x7f0000000100)=ANY=[@ANYRESDEC], 0x14) ioctl$PERF_EVENT_IOC_ENABLE(r3, 0x8912, 0x400200) sendfile(r1, r1, &(0x7f00000001c0), 0x8080fffffffe) > > ================================================================== > > BUG: KCSAN: data-race in __fat_write_inode / fat12_ent_get > > > > write to 0xffff8881015f423c of 4 bytes by task 9966 on cpu 1: > > __fat_write_inode+0x246/0x510 fs/fat/inode.c:877 > > fat_write_inode+0x67/0xe0 fs/fat/inode.c:909 > > write_inode fs/fs-writeback.c:1312 [inline] > > __writeback_single_inode+0x722/0x910 fs/fs-writeback.c:1511 > > writeback_single_inode+0x219/0x2f0 fs/fs-writeback.c:1565 > > sync_inode fs/fs-writeback.c:2602 [inline] > > sync_inode_metadata+0x75/0xa0 fs/fs-writeback.c:2622 > > __generic_file_fsync+0x117/0x180 fs/libfs.c:1081 > > fat_file_fsync+0x54/0x120 fs/fat/file.c:190 > > vfs_fsync_range+0x7c/0x150 fs/sync.c:197 > > generic_write_sync include/linux/fs.h:2867 [inline] > > generic_file_write_iter+0x31c/0x38e mm/filemap.c:3452 > > call_write_iter include/linux/fs.h:1901 [inline] > > do_iter_readv_writev+0x4a7/0x5d0 fs/read_write.c:693 > > do_iter_write fs/read_write.c:998 [inline] > > do_iter_write+0x137/0x3a0 fs/read_write.c:979 > > vfs_iter_write+0x56/0x80 fs/read_write.c:1039 > > iter_file_splice_write+0x530/0x830 fs/splice.c:760 > > do_splice_from fs/splice.c:863 [inline] > > direct_splice_actor+0x97/0xb0 fs/splice.c:1037 > > splice_direct_to_actor+0x22f/0x540 fs/splice.c:992 > > do_splice_direct+0x152/0x1d0 fs/splice.c:1080 > > do_sendfile+0x396/0x810 fs/read_write.c:1520 > > __do_sys_sendfile64 fs/read_write.c:1575 [inline] > > __se_sys_sendfile64 fs/read_write.c:1567 [inline] > > __x64_sys_sendfile64+0xb8/0x140 fs/read_write.c:1567 > > do_syscall_64+0xc7/0x390 arch/x86/entry/common.c:294 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > read to 0xffff8881015f423d of 1 bytes by task 9960 on cpu 0: > > fat12_ent_get+0x5e/0x120 fs/fat/fatent.c:125 > > fat_ent_read+0x3de/0x560 fs/fat/fatent.c:370 > > fat_get_cluster+0x52b/0x920 fs/fat/cache.c:266 > > fat_bmap_cluster fs/fat/cache.c:299 [inline] > > fat_get_mapped_cluster+0x105/0x230 fs/fat/cache.c:320 > > fat_bmap+0x146/0x28e fs/fat/cache.c:384 > > __fat_get_block fs/fat/inode.c:165 [inline] > > fat_get_block+0x244/0x4f0 fs/fat/inode.c:190 > > __block_write_begin_int+0x306/0xf80 fs/buffer.c:2008 > > __block_write_begin fs/buffer.c:2058 [inline] > > block_write_begin+0x76/0x160 fs/buffer.c:2117 > > cont_write_begin+0x3bd/0x660 fs/buffer.c:2466 > > fat_write_begin+0x69/0xc0 fs/fat/inode.c:236 > > pagecache_write_begin+0x67/0x90 mm/filemap.c:3106 > > cont_expand_zero fs/buffer.c:2393 [inline] > > cont_write_begin+0x176/0x660 fs/buffer.c:2456 > > fat_write_begin+0x69/0xc0 fs/fat/inode.c:236 > > generic_perform_write+0x13a/0x320 mm/filemap.c:3287 > > __generic_file_write_iter+0x240/0x370 mm/filemap.c:3416 > > generic_file_write_iter+0x294/0x38e mm/filemap.c:3448 > > call_write_iter include/linux/fs.h:1901 [inline] > > new_sync_write+0x303/0x400 fs/read_write.c:483 > > __vfs_write+0x9e/0xb0 fs/read_write.c:496 > > vfs_write fs/read_write.c:558 [inline] > > vfs_write+0x189/0x380 fs/read_write.c:542 > > ksys_write+0xc5/0x1a0 fs/read_write.c:611 > > __do_sys_write fs/read_write.c:623 [inline] > > __se_sys_write fs/read_write.c:620 [inline] > > __x64_sys_write+0x49/0x60 fs/read_write.c:620 > > do_syscall_64+0xc7/0x390 arch/x86/entry/common.c:294 > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > Reported by Kernel Concurrency Sanitizer on: > > CPU: 0 PID: 9960 Comm: syz-executor.1 Not tainted 5.6.0-rc1-syzkaller #0 > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 > > ================================================================== > > > > > > --- > > This bug 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@googlegroups.com. > > > > syzbot will keep track of this bug report. See: > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot. > > -- > OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> > > -- > You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group. > To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/874ku0sncc.fsf%40mail.parknet.co.jp. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: KCSAN: data-race in __fat_write_inode / fat12_ent_get 2020-04-03 16:36 ` Dmitry Vyukov @ 2020-04-04 6:14 ` OGAWA Hirofumi 2020-04-07 10:39 ` Dmitry Vyukov 0 siblings, 1 reply; 6+ messages in thread From: OGAWA Hirofumi @ 2020-04-04 6:14 UTC (permalink / raw) To: Dmitry Vyukov; +Cc: syzbot, Marco Elver, LKML, syzkaller-bugs Dmitry Vyukov <dvyukov@google.com> writes: > On Fri, Apr 3, 2020 at 3:36 PM OGAWA Hirofumi > <hirofumi@mail.parknet.co.jp> wrote: >> >> Hm, looks like the race between a directory entry vs a FAT entry. This >> bug was happened with the corrupted image? Or the image passes the check >> of dosfsck? >> >> If the corrupted image, it may be hard to prevent the all races. Well, >> anyway, the corrupted image of the report will help to detect this >> corruption. > > From the log, it's this program. > My bet on a corrupted image. syzkaller does not have format > descriptions for fat, so it's just random bytes. You meant I can regenerate a disk image from that log (if so, how)? If not, for next time, it would be helpful if syzkaller provides the log to regenerate the corrupted image (or saving a corrupted image) to reproduce this, then I can try to detect the corruption pattern early. Thanks. -- OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: KCSAN: data-race in __fat_write_inode / fat12_ent_get 2020-04-04 6:14 ` OGAWA Hirofumi @ 2020-04-07 10:39 ` Dmitry Vyukov 2020-04-07 13:03 ` OGAWA Hirofumi 0 siblings, 1 reply; 6+ messages in thread From: Dmitry Vyukov @ 2020-04-07 10:39 UTC (permalink / raw) To: OGAWA Hirofumi; +Cc: syzbot, Marco Elver, LKML, syzkaller-bugs, syzkaller [-- Attachment #1: Type: text/plain, Size: 1318 bytes --] On Sat, Apr 4, 2020 at 8:14 AM OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> wrote: > > Dmitry Vyukov <dvyukov@google.com> writes: > > > On Fri, Apr 3, 2020 at 3:36 PM OGAWA Hirofumi > > <hirofumi@mail.parknet.co.jp> wrote: > >> > >> Hm, looks like the race between a directory entry vs a FAT entry. This > >> bug was happened with the corrupted image? Or the image passes the check > >> of dosfsck? > >> > >> If the corrupted image, it may be hard to prevent the all races. Well, > >> anyway, the corrupted image of the report will help to detect this > >> corruption. > > > > From the log, it's this program. > > My bet on a corrupted image. syzkaller does not have format > > descriptions for fat, so it's just random bytes. > > You meant I can regenerate a disk image from that log (if so, how)? > > If not, for next time, it would be helpful if syzkaller provides the log > to regenerate the corrupted image (or saving a corrupted image) to > reproduce this, then I can try to detect the corruption pattern early. I've converted the program to C using syz-prog2c: https://github.com/google/syzkaller/blob/master/docs/syzbot.md#syzkaller-reproducers then slightly changed the generated program to dump the file to disk rather than mounting. The resulting image is attached (archived because it's mostly zeros). [-- Attachment #2: syz_mount_image.tar.gz --] [-- Type: application/gzip, Size: 131449 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: KCSAN: data-race in __fat_write_inode / fat12_ent_get 2020-04-07 10:39 ` Dmitry Vyukov @ 2020-04-07 13:03 ` OGAWA Hirofumi 0 siblings, 0 replies; 6+ messages in thread From: OGAWA Hirofumi @ 2020-04-07 13:03 UTC (permalink / raw) To: Dmitry Vyukov; +Cc: syzbot, Marco Elver, LKML, syzkaller-bugs, syzkaller Dmitry Vyukov <dvyukov@google.com> writes: >> You meant I can regenerate a disk image from that log (if so, how)? >> >> If not, for next time, it would be helpful if syzkaller provides the log >> to regenerate the corrupted image (or saving a corrupted image) to >> reproduce this, then I can try to detect the corruption pattern early. > > > I've converted the program to C using syz-prog2c: > https://github.com/google/syzkaller/blob/master/docs/syzbot.md#syzkaller-reproducers > then slightly changed the generated program to dump the file to disk > rather than mounting. > > The resulting image is attached (archived because it's mostly zeros). Thank you! I think I can see now why the generated image became the cause of this. -- OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-04-07 13:03 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-04-03 12:35 KCSAN: data-race in __fat_write_inode / fat12_ent_get syzbot 2020-04-03 13:36 ` OGAWA Hirofumi 2020-04-03 16:36 ` Dmitry Vyukov 2020-04-04 6:14 ` OGAWA Hirofumi 2020-04-07 10:39 ` Dmitry Vyukov 2020-04-07 13:03 ` OGAWA Hirofumi
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).