Re: [PATCH] Tried making changes

[Matthew Wilcox]

On Sat, Dec 02, 2023 at 10:09:00AM +0530, attreyee-muk wrote:
> Respected Maintainers, 
> 
> I have tried to solve the bug - UBSAN: shift-out-of-bounds in exfat_fill_super, reported by Syzbot [link - https://syzkaller.appspot.com/bug?extid=d33808a177641a02213e]

Hi Attreyee,

Working on syzbot reports is quite an art.  The important thing to know
for solving this one is that syzbot will fuzz filesystems.  That is, it
will start with a valid filesystem and change bits on disk, then see if
that creates any issues.

> The issue is in line 503 of fs/exfat/super.c - by analyzing the code, I
> understood that the it is checking if the calculated size of the exFAT
> File Allocation Table is very small as compared to the expected
> size,based on the number of clusters. If the condition is met, then an
> error will be logged. But here inside the if statement, I believe that
> the value of number of bits in sbi->num_FAT_sectors ,at some point is
> coming more than the value of p_boot->sect_size_bits. As a result, a
> shift-out-of-bounds error is being generated. 

No, that's not what's happening in this report.  p_boot->sect_size_bits
somehow has value 97.  And it's Undefined Behaviour in C to shift by more
than the number of bits in the type.  But I don't see how that happens:

fs/exfat/exfat_raw.h:#define EXFAT_MAX_SECT_SIZE_BITS           12

        if (p_boot->sect_size_bits < EXFAT_MIN_SECT_SIZE_BITS ||
            p_boot->sect_size_bits > EXFAT_MAX_SECT_SIZE_BITS) {

so something weird has happened; probably there's some other bug
somewhere else that has caused p_boot to be corrupted.  Whatever it is,
it's unlikely that you'll be able to find it.  Probably this is why
there's no reproducer.