linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).