All of lore.kernel.org
 help / color / mirror / Atom feed
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.