All of lore.kernel.org
 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 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.