Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 14 Nov 2022 12:53:03 -0500
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Waiman Long <longman@redhat.com>
Cc:     syzbot <syzbot+ea70429cd5cf47ba8937@syzkaller.appspotmail.com>,
        adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org,
        linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
        nathan@kernel.org, ndesaulniers@google.com,
        syzkaller-bugs@googlegroups.com, trix@redhat.com,
        Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Boqun Feng <boqun.feng@gmail.com>
Subject: Re: [syzbot] KASAN: slab-out-of-bounds Read in ext4_enable_quotas
Message-ID: <Y3KAfyQOf6GvEo/x@mit.edu>
References: <0000000000006a74dd05e9931449@google.com>
 <000000000000073a4a05ed620676@google.com>
 <Y3Jb1Wcs/mQlZP32@mit.edu>
 <8c3757ae-1aeb-49a4-47af-598d1d4737ea@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8c3757ae-1aeb-49a4-47af-598d1d4737ea@redhat.com>
Precedence: bulk

On Mon, Nov 14, 2022 at 11:21:33AM -0500, Waiman Long wrote:
> 
> lockdep_set_subclass() should be translated into a call to
> lockdep_init_map_type():
> 
> #define lockdep_set_subclass(lock, sub)???????????????????????????????? \
> ??????? lockdep_init_map_type(&(lock)->dep_map, #lock, (lock)->dep_map.key,
> sub,\
> (lock)->dep_map.wait_type_inner,????????? \
> (lock)->dep_map.wait_type_outer,????????? \
> ????????????????????????????? (lock)->dep_map.lock_type)
> 
> All memory access should be within the bound of the given "&ei->i_data_sem".
> Also lockdep_init_map_type() is not in the stack trace. So it is not a
> problem within this lockdep_init_map_type() function. So is it possible that
> the given inode pointer is invalid?

Well, the inode pointer would be coming from iget().  And since this
is coming from ext4 mount operation, we would be getting a fresh inode
that should be freshly allocated.  So the possibilities which comes to
mind is some kind of use-after-free (probbly in f2fs) that was
smashing the inode itself, such that ei->i_data_sem was pointing off
into la-la-land, or in the inode cache's internal data srtuctures.

The reason why I would assume it would be in f2fs is I *assume*
syzkaller would have pruned down the test case enough to remove the
messing around with mounting the invalid f2fs file system.  But the
other mystery here is why didn't KASAN report the use-after-free (if
that it is what it was) in the thousands of f2fs mount and
unmount operations before it finally triggered?

Anyway, I plan to ignore this Syzkaller unless report Syzkaller (or
someone else) can come up with a more minimal/reliable reproducer.  (I
mean, we could open a bug, but with kind of reproducer, it would get
prioritized P3 or P4 and ignored for years until it finally got closed
in a buganizer bankruptcy, so I figured I would just skip a few steps.  :-)

Cheers,

						- Ted