[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220209111832.b7rrzaadwtbhj4f5@quack3.lan>
Date: Wed, 9 Feb 2022 12:18:32 +0100
From: Jan Kara <jack@...e.cz>
To: Ritesh Harjani <riteshh@...ux.ibm.com>
Cc: Jan Kara <jack@...e.cz>,
syzbot <syzbot+afa2ca5171d93e44b348@...kaller.appspotmail.com>,
jack@...e.com, linux-ext4@...r.kernel.org,
linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com,
tytso@....edu
Subject: Re: [syzbot] KASAN: use-after-free Read in jbd2_journal_wait_updates
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@...kaller.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@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists