Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 21 Jul 2021 18:37:23 +0100
From:   Matthew Wilcox <willy@infradead.org>
To:     butt3rflyh4ck <butterflyhuangxx@gmail.com>
Cc:     LKML <linux-kernel@vger.kernel.org>, linux-fsdevel@vger.kernel.org,
        syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: A shift-out-of-bounds in minix_statfs in fs/minix/inode.c
Message-ID: <YPhbU/umyUZLdxIw@casper.infradead.org>
References: <CAFcO6XOdMe-RgN8MCUT59cYEVBp+3VYTW-exzxhKdBk57q0GYw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAFcO6XOdMe-RgN8MCUT59cYEVBp+3VYTW-exzxhKdBk57q0GYw@mail.gmail.com>
Precedence: bulk

On Thu, Jul 22, 2021 at 01:14:06AM +0800, butt3rflyh4ck wrote:
> ms = (struct minix_super_block *) bh->b_data; /// --------------> set
> minix_super_block pointer
> sbi->s_ms = ms;
> sbi->s_sbh = bh;
> sbi->s_mount_state = ms->s_state;
> sbi->s_ninodes = ms->s_ninodes;
> sbi->s_nzones = ms->s_nzones;
> sbi->s_imap_blocks = ms->s_imap_blocks;
> sbi->s_zmap_blocks = ms->s_zmap_blocks;
> sbi->s_firstdatazone = ms->s_firstdatazone;
> sbi->s_log_zone_size = ms->s_log_zone_size;  // ------------------>
> set sbi->s_log_zone_size

So what you're saying is that if you construct a malicious minix image,
you can produce undefined behaviour?  That's not something we're
traditionally interested in, unless the filesystem is one customarily
used for data interchange (like FAT or iso9660).