* 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).