Messages in this thread | | | Date | Sat, 2 Dec 2023 19:01:54 +0000 | From | Matthew Wilcox <> | Subject | Re: [PATCH] Tried making changes |
| |
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.
| |