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  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]
Date:   Mon, 14 Nov 2022 12:53:03 -0500
From:   "Theodore Ts'o" <>
To:     Waiman Long <>
Cc:     syzbot <>,,,,,,,,,
        Jaegeuk Kim <>, Chao Yu <>,
        Peter Zijlstra <>,
        Ingo Molnar <>,
        Boqun Feng <>
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.  :-)


						- Ted

Powered by blists - more mailing lists