Re: [Cluster-devel] general protection fault in gfs2_withdraw
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=11f2ff2790 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=160fb77390 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1104f10990 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+50a8a9cf8127f2c6f...@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 0xdc0e: [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0070-0x0077] 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] RIP: 0010:gfs2_withdraw+0x2b0/0xe20 fs/gfs2/util.c:294 Code: e8 03 48 89 44 24 38 42 80 3c 38 00 74 08 48 89 ef e8 34 f7 69 fe 48 89 6c 24 20 48 8b 6d 00 48 83 c5 70 48 89 e8 48 c1 e8 03 <42> 80 3c 38 00 74 08 48 89 ef e8 11 f7 69 fe 48 8b 45 00 48 89 44 RSP: 0018:c900057474f0 EFLAGS: 00010202 RAX: 000e RBX: 8880a71e RCX: 98268db4dfe86a00 RDX: 888092bb6100 RSI: RDI: 8880a71e0430 RBP: 0070 R08: 834ad50c R09: ed1015d041c3 R10: ed1015d041c3 R11: R12: 111014e3c04d R13: 8880a71e0050 R14: 8880a71e026c R15: dc00 FS: 0233b880() GS:8880ae80() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f74f826d6c0 CR3: a04cc000 CR4: 001506f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: gfs2_meta_check_ii+0x70/0x80 fs/gfs2/util.c:450 gfs2_metatype_check_i fs/gfs2/util.h:126 [inline] gfs2_meta_indirect_buffer+0x29f/0x380 fs/gfs2/meta_io.c:417 gfs2_meta_inode_buffer fs/gfs2/meta_io.h:70 [inline] gfs2_inode_refresh+0x65/0xc00 fs/gfs2/glops.c:438 inode_go_lock+0x12c/0x480 fs/gfs2/glops.c:468 do_promote+0x4db/0xcd0 fs/gfs2/glock.c:390 finish_xmote+0x907/0x1350 fs/gfs2/glock.c:560 do_xmote+0xadb/0x14c0 fs/gfs2/glock.c:686 gfs2_glock_nq+0xac3/0x14d0 fs/gfs2/glock.c:1410 gfs2_glock_nq_init fs/gfs2/glock.h:238 [inline] gfs2_lookupi+0x36f/0x4f0 fs/gfs2/inode.c:317 gfs2_lookup_simple+0xa4/0x100 fs/gfs2/inode.c:268 init_journal+0x132/0x1970 fs/gfs2/ops_fstype.c:620 init_inodes fs/gfs2/ops_fstype.c:756 [inline] gfs2_fill_super+0x2717/0x3fe0 fs/gfs2/ops_fstype.c:1125 get_tree_bdev+0x3e9/0x5f0 fs/super.c:1342 gfs2_get_tree+0x4c/0x1f0 fs/gfs2/ops_fstype.c:1201 vfs_get_tree+0x88/0x270 fs/super.c:1547 do_new_mount fs/namespace.c:2875 [inline] path_mount+0x179d/0x29e0 fs/namespace.c:3192 do_mount fs/namespace.c:3205 [inline] __do_sys_mount fs/namespace.c:3413 [inline] __se_sys_mount+0x126/0x180 fs/namespace.c:3390 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x458e1a Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 da ad fb ff c3 66 0f 1f 84 00 00 00 00 00 RSP: 002b:7ffc76f65c88 EFLAGS: 0293 ORIG_RAX: 00a5 RAX: ffda RBX: 7ffc76f65ce0 RCX: 00458e1a RDX: 2000 RSI: 2100 RDI: 7ffc76f65ca0 RBP: 7ffc76f65ca0 R08: 7ffc76f65ce0 R09: 7ffc0015 R10: R11: 0293 R12: 0809 R13: 0004 R14: 0003 R15: 0003 Modules linked in: ---[ end trace 1e62174917573e95 ]--- RIP: 0010:signal_our_withdraw fs/gfs2/util.c:97 [inline] RIP: 0010:gfs2_withdraw+0x2b0/0xe20 fs/gfs2/util.c:294 Code: e8 03 48 89 44 24 38 42 80 3c 38 00 74 08 48 89 ef e8 34 f7 69 fe 48 89 6c 24 20 48 8b 6d 00 48 83 c5 70 48 89 e8 48 c1 e8 03 <42> 80 3c 38 00 74 08 48 89 ef e8 11 f7 69 fe 48 8b 45 00 48 89 44 RSP: 0018:c900057474f0 EFLAGS: 00010202 RAX: 000e RBX: 8880a71e RCX: 98268db4dfe86a00 RDX: 888092bb6100 RSI: RDI: 8880a71e0430 RBP: 0070 R08: 834ad50c R09: ed1015d041c3 R10: ed1015d041c3 R11: R12: 111014e3c04d R13: 8880a71e0050 R14: 8880a71e026c R15: dc00 F
Re: [Cluster-devel] general protection fault in gfs2_withdraw
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=11f2ff2790
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=160fb77390
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1104f10990
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+50a8a9cf8127f2c6f...@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
0xdc0e: [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0070-0x0077]
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
RIP: 0010:gfs2_withdraw+0x2b0/0xe20 fs/gfs2/util.c:294
Code: e8 03 48 89 44 24 38 42 80 3c 38 00 74 08 48 89 ef e8 34 f7 69 fe 48 89 6c 24
20 48 8b 6d 00 48 83 c5 70 48 89 e8 48 c1 e8 03 <42> 80 3c 38 00 74 08 48 89 ef
e8 11 f7 69 fe 48 8b 45 00 48 89 44
RSP: 0018:c900057474f0 EFLAGS: 00010202
RAX: 000e RBX: 8880a71e RCX: 98268db4dfe86a00
RDX: 888092bb6100 RSI: RDI: 8880a71e0430
RBP: 0070 R08: 834ad50c R09: ed1015d041c3
R10: ed1015d041c3 R11: R12: 111014e3c04d
R13: 8880a71e0050 R14: 8880a71e026c R15: dc00
FS: 0233b880() GS:8880ae80() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f74f826d6c0 CR3: a04cc000 CR4: 001506f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
gfs2_meta_check_ii+0x70/0x80 fs/gfs2/util.c:450
gfs2_metatype_check_i fs/gfs2/util.h:126 [inline]
gfs2_meta_indirect_buffer+0x29f/0x380 fs/gfs2/meta_io.c:417
gfs2_meta_inode_buffer fs/gfs2/meta_io.h:70 [inline]
gfs2_inode_refresh+0x65/0xc00 fs/gfs2/glops.c:438
inode_go_lock+0x12c/0x480 fs/gfs2/glops.c:468
do_promote+0x4db/0xcd0 fs/gfs2/glock.c:390
finish_xmote+0x907/0x1350 fs/gfs2/glock.c:560
do_xmote+0xadb/0x14c0 fs/gfs2/glock.c:686
gfs2_glock_nq+0xac3/0x14d0 fs/gfs2/glock.c:1410
gfs2_glock_nq_init fs/gfs2/glock.h:238 [inline]
gfs2_lookupi+0x36f/0x4f0 fs/gfs2/inode.c:317
gfs2_lookup_simple+0xa4/0x100 fs/gfs2/inode.c:268
init_journal+0x132/0x1970 fs/gfs2/ops_fstype.c:620
init_inodes fs/gfs2/ops_fstype.c:756 [inline]
gfs2_fill_super+0x2717/0x3fe0 fs/gfs2/ops_fstype.c:1125
get_tree_bdev+0x3e9/0x5f0 fs/super.c:1342
gfs2_get_tree+0x4c/0x1f0 fs/gfs2/ops_fstype.c:1201
vfs_get_tree+0x88/0x270 fs/super.c:1547
do_new_mount fs/namespace.c:2875 [inline]
path_mount+0x179d/0x29e0 fs/namespace.c:3192
do_mount fs/namespace.c:3205 [inline]
__do_sys_mount fs/namespace.c:3413 [inline]
__se_sys_mount+0x126/0x180 fs/namespace.c:3390
do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x458e1a
Code: b8 08 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 fd ad fb ff c3 66 2e 0f 1f 84 00
00 00 00 00 66 90 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 da ad
fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:7ffc76f65c88 EFLAGS: 0293 ORIG_RAX: 00a5
RAX: ffda RBX: 7ffc76f65ce0 RCX: 00458e1a
RDX: 2000 RSI: 2100 RDI: 7ffc76f65ca0
RBP: 7ffc76f65ca0 R08: 7ffc76f65ce0 R09: 7ffc0015
R10: R11: 0293 R12: 0809
R13: 0004 R14: 0003 R15: 0003
Modules linked in:
---[ end trace 1e62174917573e95 ]---
RIP: 0010:signal_our_withdraw fs/gfs2/util.c:97 [inline]
RIP: 0010:
Re: [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=11f2ff2790
> > 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=160fb77390
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1104f10990
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the
> > commit:
> > Reported-by: syzbot+50a8a9cf8127f2c6f...@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
> > 0xdc0e: [#1] PREEMPT SMP KASAN
> > KASAN: null-ptr-deref in range [0x0070-0x0077]
> > 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
