Re: [syzbot] KASAN: use-after-free Read in jbd2_journal_wait_updates

[Jan Kara <jack@suse.cz>]

On Wed 09-02-22 15:26:47, Ritesh Harjani wrote:
> On 22/02/08 05:14PM, Jan Kara wrote:
> > On Tue 08-02-22 04:49:19, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:    555f3d7be91a Merge tag '5.17-rc3-ksmbd-server-fixes' of gi..
> > > git tree:       upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=17e55852700000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=88e0a6a3dbf057cf
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=afa2ca5171d93e44b348
> > > compiler:       Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2
> > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=13b03872700000
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+afa2ca5171d93e44b348@syzkaller.appspotmail.com
> >
> > So the syzbot reproducer looks bogus to me but the bug is real.
> > jbd2_journal_wait_updates() looks at commit_transaction after dropping
> > j_state_lock and sleeping which is certainly prone to use-after-free
> > issues.
> 
> Yes, thanks for taking a look at it.
> 
> >
> > Funnily, Ritesh's removal of t_handle_lock should "fix" the problem by
> > removing this dereference. So Ritesh, please just add some reference to
> > syzbot report and maybe a backport to stable would be warranted.
> >
> 
> This actually looks like a regression because of commit [1].
> So I am thinking of sending a separate patch [2] as a fix for this (after my
> testing).

Yeah, and my fault for not catching this during review :-|. Anyway the
proposed fix looks good.

> Not sure why fstests testing didn't pick this up (given it's a common race),
> or is it because of my recent removal of CONFIG_KASAN from my testing :(
> 
> I will try a full "auto" test with CONFIG_KASAN enabled and see if we could hit
> this in fstests or not. If not then I will work towards adding a targetted test
> to capture such race.

Yeah, without KASAN this could lead to memory corruption by the spin_lock()
but in most cases it will just pass by unnoticed because the memory does
not get reused so quickly.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR