From: Leon Romanovsky <leon@kernel.org>
To: Doug Ledford <dledford@redhat.com>, Jason Gunthorpe <jgg@nvidia.com>
Cc: Mark Zhang <markzhang@nvidia.com>,
Ira Weiny <ira.weiny@intel.com>,
John Fleck <john.fleck@intel.com>,
Kaike Wan <kaike.wan@intel.com>,
linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
Mark Bloch <markb@mellanox.com>, Mark Bloch <mbloch@nvidia.com>
Subject: [PATCH rdma-rc 1/2] RDMA/sa_query: Use strscpy_pad instead of memcpy to copy a string
Date: Sun, 24 Oct 2021 09:08:20 +0300 [thread overview]
Message-ID: <72ede0f6dab61f7f23df9ac7a70666e07ef314b0.1635055496.git.leonro@nvidia.com> (raw)
In-Reply-To: <cover.1635055496.git.leonro@nvidia.com>
From: Mark Zhang <markzhang@nvidia.com>
When copy the device name, the length of data memcpy copied exceeds
the length of the source buffer, which cause the KASAN issue below.
Use strscpy_pad instead.
BUG: KASAN: slab-out-of-bounds in ib_nl_set_path_rec_attrs+0x136/0x320 [ib_core]
Read of size 64 at addr ffff88811a10f5e0 by task rping/140263
CPU: 3 PID: 140263 Comm: rping Not tainted 5.15.0-rc1+ #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
dump_stack_lvl+0x57/0x7d
print_address_description.constprop.0+0x1d/0xa0
kasan_report+0xcb/0x110
? lock_downgrade+0xb0/0xc0
? ib_nl_set_path_rec_attrs+0x136/0x320 [ib_core]
kasan_check_range+0x13d/0x180
memcpy+0x20/0x60
ib_nl_set_path_rec_attrs+0x136/0x320 [ib_core]
? init_mad+0xf0/0xf0 [ib_core]
? __nlmsg_put+0x9a/0xb0
? ibnl_put_msg+0x90/0xd0 [ib_core]
ib_nl_make_request+0x1c6/0x380 [ib_core]
? ib_nl_set_path_rec_attrs+0x320/0x320 [ib_core]
? netlink_has_listeners+0x114/0x210
send_mad+0x20a/0x220 [ib_core]
? ib_nl_make_request+0x380/0x380 [ib_core]
? memcpy+0x39/0x60
? value_read+0x20/0x80 [ib_core]
? ib_pack+0x140/0x2a0 [ib_core]
ib_sa_path_rec_get+0x3e3/0x800 [ib_core]
? alloc_mad+0x390/0x390 [ib_core]
? __kasan_kmalloc+0x7c/0x90
? rdma_resolve_route+0x37b/0x3e0 [rdma_cm]
? ucma_resolve_route+0xe1/0x150 [rdma_ucm]
? ucma_write+0x17b/0x1f0 [rdma_ucm]
? vfs_write+0x142/0x4d0
? ksys_write+0x133/0x160
? do_syscall_64+0x43/0x90
? entry_SYSCALL_64_after_hwframe+0x44/0xae
? print_usage_bug+0x50/0x50
? lock_downgrade+0xc0/0xc0
cma_query_ib_route+0x29b/0x390 [rdma_cm]
? rdma_set_ib_path+0x150/0x150 [rdma_cm]
? lockdep_hardirqs_on_prepare+0x12e/0x200
? rdma_create_user_id+0x80/0x80 [rdma_cm]
? rdma_resolve_route+0x37b/0x3e0 [rdma_cm]
? rdma_resolve_route+0x308/0x3e0 [rdma_cm]
rdma_resolve_route+0x308/0x3e0 [rdma_cm]
ucma_resolve_route+0xe1/0x150 [rdma_ucm]
? ucma_disconnect+0x140/0x140 [rdma_ucm]
ucma_write+0x17b/0x1f0 [rdma_ucm]
? ucma_copy_ib_route+0x1a0/0x1a0 [rdma_ucm]
? __fget_files+0x146/0x240
vfs_write+0x142/0x4d0
ksys_write+0x133/0x160
? __ia32_sys_read+0x50/0x50
? lockdep_hardirqs_on_prepare+0x12e/0x200
? syscall_enter_from_user_mode+0x1d/0x50
do_syscall_64+0x43/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f26499aa90f
Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 29 fd ff ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 5c fd ff ff 48
RSP: 002b:00007f26495f2dc0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00000000000007d0 RCX: 00007f26499aa90f
RDX: 0000000000000010 RSI: 00007f26495f2e00 RDI: 0000000000000003
RBP: 00005632a8315440 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000293 R12: 00007f26495f2e00
R13: 00005632a83154e0 R14: 00005632a8315440 R15: 00005632a830a810
Allocated by task 131419:
kasan_save_stack+0x1b/0x40
__kasan_kmalloc+0x7c/0x90
proc_self_get_link+0x8b/0x100
pick_link+0x4f1/0x5c0
step_into+0x2eb/0x3d0
walk_component+0xc8/0x2c0
link_path_walk+0x3b8/0x580
path_openat+0x101/0x230
do_filp_open+0x12e/0x240
do_sys_openat2+0x115/0x280
__x64_sys_openat+0xce/0x140
do_syscall_64+0x43/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae
The buggy address belongs to the object at ffff88811a10f5e0
kmalloc-16 of size 16
The buggy address is located 0 bytes inside of
10f5e0, ffff88811a10f5f0)
The buggy address belongs to the page:
page:000000007b6da7b1 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88811a10f1e0 pfn:0x11a10f
flags: 0x8000000000000200(slab|zone=2)
raw: 8000000000000200 ffffea0004463040 0000001200000012 ffff8881000423c0
raw: ffff88811a10f1e0 000000008080007f 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88811a10f480: fa fb fc fc fa fb fc fc fa fb fc fc fa fb fc fc
ffff88811a10f500: fa fb fc fc fa fb fc fc 00 00 fc fc 00 00 fc fc
>ffff88811a10f580: 00 00 fc fc fa fb fc fc 00 00 fc fc 00 00 fc fc
^
ffff88811a10f600: 00 00 fc fc fa fb fc fc fa fb fc fc 00 00 fc fc
ffff88811a10f680: 00 00 fc fc 00 00 fc fc fa fb fc fc 00 00 fc fc
Fixes: 2ca546b92a02 ("IB/sa: Route SA pathrecord query through netlink")
Signed-off-by: Mark Zhang <markzhang@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
drivers/infiniband/core/sa_query.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/core/sa_query.c b/drivers/infiniband/core/sa_query.c
index 4220a545387f..74ecd7456a11 100644
--- a/drivers/infiniband/core/sa_query.c
+++ b/drivers/infiniband/core/sa_query.c
@@ -706,8 +706,9 @@ static void ib_nl_set_path_rec_attrs(struct sk_buff *skb,
/* Construct the family header first */
header = skb_put(skb, NLMSG_ALIGN(sizeof(*header)));
- memcpy(header->device_name, dev_name(&query->port->agent->device->dev),
- LS_DEVICE_NAME_MAX);
+ strscpy_pad(header->device_name,
+ dev_name(&query->port->agent->device->dev),
+ LS_DEVICE_NAME_MAX);
header->port_num = query->port->port_num;
if ((comp_mask & IB_SA_PATH_REC_REVERSIBLE) &&
--
2.31.1
next prev parent reply other threads:[~2021-10-24 6:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-24 6:08 [PATCH rdma-rc 0/2] Two IB/core fixes Leon Romanovsky
2021-10-24 6:08 ` Leon Romanovsky [this message]
2021-10-25 17:02 ` [PATCH rdma-rc 1/2] RDMA/sa_query: Use strscpy_pad instead of memcpy to copy a string Jason Gunthorpe
2021-10-24 6:08 ` [PATCH rdma-rc 2/2] RDMA/core: Initialize lock when allocate a rdma_hw_stats structure Leon Romanovsky
2021-10-25 14:50 ` Jason Gunthorpe
2021-10-26 8:27 ` Leon Romanovsky
2021-10-26 12:05 ` Jason Gunthorpe
2021-10-26 12:21 ` Leon Romanovsky
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=72ede0f6dab61f7f23df9ac7a70666e07ef314b0.1635055496.git.leonro@nvidia.com \
--to=leon@kernel.org \
--cc=dledford@redhat.com \
--cc=ira.weiny@intel.com \
--cc=jgg@nvidia.com \
--cc=john.fleck@intel.com \
--cc=kaike.wan@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=markb@mellanox.com \
--cc=markzhang@nvidia.com \
--cc=mbloch@nvidia.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 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.