On Mon, 14 Nov 2022 at 18:53, Theodore Ts'o <tytso@xxxxxxx> 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
