All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peng Zhang <zhangpeng362@huawei.com>
To: <konishi.ryusuke@gmail.com>, <ye.xingchen@zte.com.cn>,
	<chi.minghao@zte.com.cn>, <vishal.moola@gmail.com>,
	<linux-nilfs@vger.kernel.org>
Cc: <linux-kernel@vger.kernel.org>,
	ZhangPeng <zhangpeng362@huawei.com>,
	<syzbot+ebe05ee8e98f755f61d0@syzkaller.appspotmail.com>
Subject: [PATCH] nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry()
Date: Mon, 14 Nov 2022 04:04:41 +0000	[thread overview]
Message-ID: <20221114040441.1649940-1-zhangpeng362@huawei.com> (raw)

From: ZhangPeng <zhangpeng362@huawei.com>

Syzbot reported a null-ptr-deref bug:

NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP
frequency < 30 seconds
general protection fault, probably for non-canonical address
0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 PID: 3603 Comm: segctord Not tainted
6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google
10/11/2022
RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0
fs/nilfs2/alloc.c:608
Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00
00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02
00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7
RSP: 0018:ffffc90003dff830 EFLAGS: 00010212
RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d
RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010
RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f
R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158
R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004
FS:  0000000000000000(0000) GS:ffff8880b9b00000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0
Call Trace:
 <TASK>
 nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline]
 nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193
 nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236
 nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940
 nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline]
 nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline]
 nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088
 nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337
 nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568
 nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018
 nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067
 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline]
 nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline]
 nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045
 nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379
 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline]
 nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570
 kthread+0x2e4/0x3a0 kernel/kthread.c:376
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0
fs/nilfs2/alloc.c:608
Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00
00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02
00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7
RSP: 0018:ffffc90003dff830 EFLAGS: 00010212
RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d
RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010
RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f
R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158
R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004
FS:  0000000000000000(0000) GS:ffff8880b9b00000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0
----------------
Code disassembly (best guess), 7 bytes skipped:
   0:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1)
   4:	0f 85 cd 05 00 00    	jne    0x5d7
   a:	48 b8 00 00 00 00 00 	movabs $0xdffffc0000000000,%rax
  11:	fc ff df
  14:	4c 8b 73 08          	mov    0x8(%rbx),%r14
  18:	49 8d 7e 10          	lea    0x10(%r14),%rdi
  1c:	48 89 fa             	mov    %rdi,%rdx
  1f:	48 c1 ea 03          	shr    $0x3,%rdx
* 23:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1) <-- trapping
instruction
  27:	0f 85 26 05 00 00    	jne    0x553
  2d:	49 8b 46 10          	mov    0x10(%r14),%rax
  31:	be a6 00 00 00       	mov    $0xa6,%esi
  36:	48                   	rex.W
  37:	c7                   	.byte 0xc7
  38:	c7                   	.byte 0xc7

When maxlevelp is 1, there is a case where req->pr_desc_bh is NULL and
blocknr is 0, because nilfs_dat_commit_alloc() will modify the blocknr
of oldreq at one level higher to 0. And we don't have a NULL check on
req->pr_desc_bh and req->pr_bitmap_bh in
nilfs_palloc_commit_free_entry() function, so when req->pr_desc_bh is
NULL and kmap() dereferences a NULL pointer, it leads to above crash.
Fix this by adding a NULL check on req->pr_desc_bh and req->pr_bitmap_bh
before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free().

Reported-by: syzbot+ebe05ee8e98f755f61d0@syzkaller.appspotmail.com
Fixes: bd8169efae8b ("nilfs2: add update functions of virtual block address to dat")
Signed-off-by: ZhangPeng <zhangpeng362@huawei.com>
---
 fs/nilfs2/dat.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/nilfs2/dat.c b/fs/nilfs2/dat.c
index 3b55e239705f..84ce050a8fa3 100644
--- a/fs/nilfs2/dat.c
+++ b/fs/nilfs2/dat.c
@@ -111,6 +111,9 @@ static void nilfs_dat_commit_free(struct inode *dat,
 	kunmap_atomic(kaddr);
 
 	nilfs_dat_commit_entry(dat, req);
+
+	if (req->pr_desc_bh == NULL || req->pr_bitmap_bh == NULL)
+		return;
 	nilfs_palloc_commit_free_entry(dat, req);
 }
 
-- 
2.25.1


WARNING: multiple messages have this Message-ID (diff)
From: Peng Zhang <zhangpeng362-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: konishi.ryusuke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	ye.xingchen-Th6q7B73Y6EnDS1+zs4M5A@public.gmane.org,
	chi.minghao-Th6q7B73Y6EnDS1+zs4M5A@public.gmane.org,
	vishal.moola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	ZhangPeng <zhangpeng362-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	syzbot+ebe05ee8e98f755f61d0-Pl5Pbv+GP7P466ipTTIvnc23WoclnBCfAL8bYrjMMd8@public.gmane.org
Subject: [PATCH] nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry()
Date: Mon, 14 Nov 2022 04:04:41 +0000	[thread overview]
Message-ID: <20221114040441.1649940-1-zhangpeng362@huawei.com> (raw)

From: ZhangPeng <zhangpeng362-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

Syzbot reported a null-ptr-deref bug:

NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP
frequency < 30 seconds
general protection fault, probably for non-canonical address
0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 PID: 3603 Comm: segctord Not tainted
6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0
Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google
10/11/2022
RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0
fs/nilfs2/alloc.c:608
Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00
00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02
00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7
RSP: 0018:ffffc90003dff830 EFLAGS: 00010212
RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d
RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010
RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f
R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158
R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004
FS:  0000000000000000(0000) GS:ffff8880b9b00000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0
Call Trace:
 <TASK>
 nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline]
 nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193
 nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236
 nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940
 nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline]
 nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline]
 nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088
 nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337
 nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568
 nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018
 nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067
 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline]
 nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline]
 nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045
 nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379
 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline]
 nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570
 kthread+0x2e4/0x3a0 kernel/kthread.c:376
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
 </TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0
fs/nilfs2/alloc.c:608
Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00
00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02
00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7
RSP: 0018:ffffc90003dff830 EFLAGS: 00010212
RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d
RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010
RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f
R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158
R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004
FS:  0000000000000000(0000) GS:ffff8880b9b00000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0
----------------
Code disassembly (best guess), 7 bytes skipped:
   0:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1)
   4:	0f 85 cd 05 00 00    	jne    0x5d7
   a:	48 b8 00 00 00 00 00 	movabs $0xdffffc0000000000,%rax
  11:	fc ff df
  14:	4c 8b 73 08          	mov    0x8(%rbx),%r14
  18:	49 8d 7e 10          	lea    0x10(%r14),%rdi
  1c:	48 89 fa             	mov    %rdi,%rdx
  1f:	48 c1 ea 03          	shr    $0x3,%rdx
* 23:	80 3c 02 00          	cmpb   $0x0,(%rdx,%rax,1) <-- trapping
instruction
  27:	0f 85 26 05 00 00    	jne    0x553
  2d:	49 8b 46 10          	mov    0x10(%r14),%rax
  31:	be a6 00 00 00       	mov    $0xa6,%esi
  36:	48                   	rex.W
  37:	c7                   	.byte 0xc7
  38:	c7                   	.byte 0xc7

When maxlevelp is 1, there is a case where req->pr_desc_bh is NULL and
blocknr is 0, because nilfs_dat_commit_alloc() will modify the blocknr
of oldreq at one level higher to 0. And we don't have a NULL check on
req->pr_desc_bh and req->pr_bitmap_bh in
nilfs_palloc_commit_free_entry() function, so when req->pr_desc_bh is
NULL and kmap() dereferences a NULL pointer, it leads to above crash.
Fix this by adding a NULL check on req->pr_desc_bh and req->pr_bitmap_bh
before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free().

Reported-by: syzbot+ebe05ee8e98f755f61d0-Pl5Pbv+GP7P466ipTTIvnc23WoclnBCfAL8bYrjMMd8@public.gmane.org
Fixes: bd8169efae8b ("nilfs2: add update functions of virtual block address to dat")
Signed-off-by: ZhangPeng <zhangpeng362-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
 fs/nilfs2/dat.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/nilfs2/dat.c b/fs/nilfs2/dat.c
index 3b55e239705f..84ce050a8fa3 100644
--- a/fs/nilfs2/dat.c
+++ b/fs/nilfs2/dat.c
@@ -111,6 +111,9 @@ static void nilfs_dat_commit_free(struct inode *dat,
 	kunmap_atomic(kaddr);
 
 	nilfs_dat_commit_entry(dat, req);
+
+	if (req->pr_desc_bh == NULL || req->pr_bitmap_bh == NULL)
+		return;
 	nilfs_palloc_commit_free_entry(dat, req);
 }
 
-- 
2.25.1


             reply	other threads:[~2022-11-14  3:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-14  4:04 Peng Zhang [this message]
2022-11-14  4:04 ` [PATCH] nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry() Peng Zhang
2022-11-14 18:39 ` Ryusuke Konishi
2022-11-14 18:39   ` Ryusuke Konishi
2022-11-19  0:38   ` Ryusuke Konishi
2022-11-19  0:38     ` Ryusuke Konishi
2022-11-19  1:02     ` Ryusuke Konishi
2022-11-19  1:02       ` Ryusuke Konishi
     [not found]     ` <422d9c54-a119-b2a2-f381-11f83af3d9ea@huawei.com>
2022-11-19  7:24       ` Ryusuke Konishi
2022-11-19  7:24         ` Ryusuke Konishi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221114040441.1649940-1-zhangpeng362@huawei.com \
    --to=zhangpeng362@huawei.com \
    --cc=chi.minghao@zte.com.cn \
    --cc=konishi.ryusuke@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nilfs@vger.kernel.org \
    --cc=syzbot+ebe05ee8e98f755f61d0@syzkaller.appspotmail.com \
    --cc=vishal.moola@gmail.com \
    --cc=ye.xingchen@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.