Hi, Thank you very much for taking a look at this report! On Wed, Nov 29, 2023 at 3:10 PM Namjae Jeon <linkinjeon@xxxxxxxxxx> wrote: > > 2023-11-28 6:03 GMT+09:00, syzbot > <syzbot+listb51f932ee38ecac1b05d@xxxxxxxxxxxxxxxxxxxxxxxxx>: > > Hello exfat maintainers/developers, > Hi, > > > > This is a 31-day syzbot report for the exfat subsystem. > > All related reports/information can be found at: > > https://syzkaller.appspot.com/upstream/s/exfat > > > > During the period, 1 new issues were detected and 0 were fixed. > > In total, 7 issues are still open and 12 have been fixed so far. > > > > Some of the still happening issues: > > > > Ref Crashes Repro Title > > <1> 225 No INFO: task hung in path_openat (7) > There is no reproducer and I couldn't find where it is connected to exfat. > > > > https://syzkaller.appspot.com/bug?extid=950a0cdaa2fdd14f5bdc Syzbot assigned exfat because of this report: https://syzkaller.appspot.com/text?tag=CrashReport&x=10e02711680000 But it indeed does look like a false positive, let's update the subsystem. #syz set <1> subsystems: fs > > <2> 150 No INFO: task hung in exfat_sync_fs > There is no reproducer... Let me know how to reproduce it. Syzbot has not yet found a reproducer for it, even though it does not seem to be very rare (there've been already >150 such crashes). There's a command to hide the finding from monthly reports if you believe this is not actionable for you anyway. > This can happen when disk speed is very low and a lot of writes occur. > Is that so? > > > > > https://syzkaller.appspot.com/bug?extid=205c2644abdff9d3f9fc > > <3> 119 Yes WARNING in drop_nlink (2) > I'm curious how this issue was classified as an exfat issue. > When looking at the backtrace, this issue appears to be an hfsplus issue. > > hfsplus_unlink+0x3fe/0x790 fs/hfsplus/dir.c:381 > hfsplus_rename+0xc8/0x1c0 fs/hfsplus/dir.c:547 > vfs_rename+0xaba/0xde0 fs/namei.c:4844 > > > > https://syzkaller.appspot.com/bug?extid=651ca866e5e2b4b5095b This is triggered by both hfsplus and exfat mounts. See e.g. the crash at "2023/06/20 03:21": https://syzkaller.appspot.com/text?tag=CrashReport&x=1248deff280000 > > <4> 38 Yes INFO: task hung in exfat_write_inode > I could not reproduce this by using C reproducer provided by you. > Can you confirm that this really cannot be reproduced using it? > > > > > https://syzkaller.appspot.com/bug?extid=2f73ed585f115e98aee8 I've followed the guide at [1] and the C reproducer crashed the VM in ~420 seconds with exactly the same output as on sykaller.appspot.com. [1] https://github.com/google/syzkaller/blob/master/docs/syzbot_assets.md#run-a-c-reproducer > > <5> 1 No UBSAN: shift-out-of-bounds in exfat_fill_super (2) > This is false alarm. ->sect_size_bits could not be greater than 12 by > the check below. > > /* > * sect_size_bits could be at least 9 and at most 12. > */ > if (p_boot->sect_size_bits < EXFAT_MIN_SECT_SIZE_BITS || > p_boot->sect_size_bits > EXFAT_MAX_SECT_SIZE_BITS) { > exfat_err(sb, "bogus sector size bits : %u", > p_boot->sect_size_bits); > return -EINVAL; > } > > > > https://syzkaller.appspot.com/bug?extid=d33808a177641a02213e Maybe something corrupts it in between the check and the use? Syzkaller may generate a lot of situations when mount and other operations on the same block device happen simultaneously. There's a patch series[2] that helps prohibit this, but it has not yet reached all trees we fuzz. [2] https://lore.kernel.org/all/20231101173542.23597-1-jack@xxxxxxx/ -- Aleksandr
