linux-ext4 - 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] [day] [month] [year] [list]

Date:   Thu, 20 Jul 2023 17:17:46 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     "Theodore Ts'o" <tytso@....edu>
Cc:     Waiman Long <longman@...hat.com>,
        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, 14 Nov 2022 at 18:53, Theodore Ts'o <tytso@....edu> wrote:
>
> 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.  :-)


Let's set the subsystem then, so it's in the f2fs bucket rather than in ext4:

#syz set subsystems: f2fs