lkml.org 
[lkml]   [2020]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Cluster-devel] general protection fault in gfs2_withdraw
----- Original Message -----
> On 26/09/2020 18:21, syzbot wrote:
> > syzbot has found a reproducer for the following issue on:
> >
> > HEAD commit: 7c7ec322 Merge tag 'for-linus' of
> > git://git.kernel.org/pub..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=11f2ff27900000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=6184b75aa6d48d66
> > dashboard link:
> > https://syzkaller.appspot.com/bug?extid=50a8a9cf8127f2c6f5df
> > compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/
> > c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=160fb773900000
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1104f109900000
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the
> > commit:
> > Reported-by: syzbot+50a8a9cf8127f2c6f5df@syzkaller.appspotmail.com
> >
> > gfs2: fsid=syz:syz.0: fatal: invalid metadata block
> > bh = 2072 (magic number)
> > function = gfs2_meta_indirect_buffer, file = fs/gfs2/meta_io.c, line =
> > 417
> > gfs2: fsid=syz:syz.0: about to withdraw this file system
> > general protection fault, probably for non-canonical address
> > 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN
> > KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
> > CPU: 0 PID: 6842 Comm: syz-executor264 Not tainted 5.9.0-rc6-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > RIP: 0010:signal_our_withdraw fs/gfs2/util.c:97 [inline]
>
> Seems that it's withdrawing in the init_inodes() path early enough
> (while looking up the jindex) that sdp->sd_jdesc is still NULL here:
>
> static void signal_our_withdraw(struct gfs2_sbd *sdp)
> {
> struct gfs2_glock *gl = sdp->sd_live_gh.gh_gl;
> struct inode *inode = sdp->sd_jdesc->jd_inode;
>
> I'm undecided as to whether the bug is that we're withdrawing that early
> at all, or that we're not checking for NULL there?
>
> Probably introduced by:
>
> 601ef0d52e96 gfs2: Force withdraw to replay journals and wait for it to
> finish
>
> Andy

Hi Andy. Thanks for your analysis.

I suspect you're right.
It's probably another exception to the rule. We knew there would be a few of
those with 601ef0d52e96, such as the one we made for "withdrawing during withdraw".
We should probably just add a check for NULL and make it do the right thing.

Regards,

Bob Peterson

\
 
 \ /
  Last update: 2020-09-28 15:53    [W:0.026 / U:6.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site