linux-kernel - Re: [syzbot] KASAN: slab-out-of-bounds Read in ext4_enable

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y3KAfyQOf6GvEo/x@mit.edu>
Date:   Mon, 14 Nov 2022 12:53:03 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     Waiman Long <longman@...hat.com>
Cc:     syzbot <syzbot+ea70429cd5cf47ba8937@...kaller.appspotmail.com>,
        adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
        nathan@...nel.org, ndesaulniers@...gle.com,
        syzkaller-bugs@...glegroups.com, trix@...hat.com,
        Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <chao@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Boqun Feng <boqun.feng@...il.com>
Subject: Re: [syzbot] KASAN: slab-out-of-bounds Read in ext4_enable_quotas

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