From: Li Lingfeng <lilingfeng3@huawei.com>
To: <chuck.lever@oracle.com>, <jlayton@kernel.org>, <neilb@suse.de>,
<okorniev@redhat.com>, <Dai.Ngo@oracle.com>, <tom@talpey.com>
Cc: <linux-nfs@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<yukuai1@huaweicloud.com>, <houtao1@huawei.com>,
<yi.zhang@huawei.com>, <yangerkun@huawei.com>,
<lilingfeng@huaweicloud.com>, <lilingfeng3@huawei.com>
Subject: [PATCH] nfsd: return -EINVAL when namelen is 0
Date: Tue, 3 Sep 2024 19:14:46 +0800 [thread overview]
Message-ID: <20240903111446.659884-1-lilingfeng3@huawei.com> (raw)
When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may
result in namelen being 0, which will cause memdup_user() to return
ZERO_SIZE_PTR.
When we access the name.data that has been assigned the value of
ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is
triggered.
[ T1205] ==================================================================
[ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260
[ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205
[ T1205]
[ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406
[ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
[ T1205] Call Trace:
[ T1205] dump_stack+0x9a/0xd0
[ T1205] ? nfs4_client_to_reclaim+0xe9/0x260
[ T1205] __kasan_report.cold+0x34/0x84
[ T1205] ? nfs4_client_to_reclaim+0xe9/0x260
[ T1205] kasan_report+0x3a/0x50
[ T1205] nfs4_client_to_reclaim+0xe9/0x260
[ T1205] ? nfsd4_release_lockowner+0x410/0x410
[ T1205] cld_pipe_downcall+0x5ca/0x760
[ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0
[ T1205] ? down_write_killable_nested+0x170/0x170
[ T1205] ? avc_policy_seqno+0x28/0x40
[ T1205] ? selinux_file_permission+0x1b4/0x1e0
[ T1205] rpc_pipe_write+0x84/0xb0
[ T1205] vfs_write+0x143/0x520
[ T1205] ksys_write+0xc9/0x170
[ T1205] ? __ia32_sys_read+0x50/0x50
[ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110
[ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110
[ T1205] do_syscall_64+0x33/0x40
[ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1
[ T1205] RIP: 0033:0x7fdbdb761bc7
[ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514
[ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7
[ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008
[ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001
[ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b
[ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000
[ T1205] ==================================================================
Fix it by checking namelen.
Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
---
fs/nfsd/nfs4recover.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/fs/nfsd/nfs4recover.c b/fs/nfsd/nfs4recover.c
index 67d8673a9391..69a3a84e159e 100644
--- a/fs/nfsd/nfs4recover.c
+++ b/fs/nfsd/nfs4recover.c
@@ -809,6 +809,10 @@ __cld_pipe_inprogress_downcall(const struct cld_msg_v2 __user *cmsg,
ci = &cmsg->cm_u.cm_clntinfo;
if (get_user(namelen, &ci->cc_name.cn_len))
return -EFAULT;
+ if (!namelen) {
+ dprintk("%s: namelen should not be zero", __func__);
+ return -EINVAL;
+ }
name.data = memdup_user(&ci->cc_name.cn_id, namelen);
if (IS_ERR(name.data))
return PTR_ERR(name.data);
@@ -831,6 +835,10 @@ __cld_pipe_inprogress_downcall(const struct cld_msg_v2 __user *cmsg,
cnm = &cmsg->cm_u.cm_name;
if (get_user(namelen, &cnm->cn_len))
return -EFAULT;
+ if (!namelen) {
+ dprintk("%s: namelen should not be zero", __func__);
+ return -EINVAL;
+ }
name.data = memdup_user(&cnm->cn_id, namelen);
if (IS_ERR(name.data))
return PTR_ERR(name.data);
--
2.31.1
next reply other threads:[~2024-09-03 11:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-03 11:14 Li Lingfeng [this message]
2024-09-03 11:23 ` [PATCH] nfsd: return -EINVAL when namelen is 0 Jeff Layton
2024-09-03 15:27 ` Chuck Lever
2024-09-03 15:35 ` Jeff Layton
2024-09-03 21:35 ` Chuck Lever
2024-09-04 13:06 ` Guoqing Jiang
2024-09-04 14:16 ` Chuck Lever
2024-09-04 14:48 ` Scott Mayhew
2024-09-05 1:25 ` Li Lingfeng
2024-09-08 20:25 ` David Laight
2024-09-09 11:24 ` Scott Mayhew
2024-09-09 11:33 ` David Laight
2024-09-09 14:10 ` Chuck Lever
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=20240903111446.659884-1-lilingfeng3@huawei.com \
--to=lilingfeng3@huawei.com \
--cc=Dai.Ngo@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=houtao1@huawei.com \
--cc=jlayton@kernel.org \
--cc=lilingfeng@huaweicloud.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=okorniev@redhat.com \
--cc=tom@talpey.com \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai1@huaweicloud.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox