linux-kernel - Re: [PATCH] Tried making changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZWt/IpxyUu+4+bxE@casper.infradead.org>
Date:   Sat, 2 Dec 2023 19:01:54 +0000
From:   Matthew Wilcox <willy@...radead.org>
To:     attreyee-muk <tintinm2017@...il.com>
Cc:     linkinjeon@...nel.org, sj1557.seo@...sung.com,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
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.