From: Jason Gunthorpe <jgg@nvidia.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Doug Ledford <dledford@redhat.com>,
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: Re: [PATCH rdma-rc 1/2] RDMA/sa_query: Use strscpy_pad instead of memcpy to copy a string
Date: Mon, 25 Oct 2021 14:02:42 -0300 [thread overview]
Message-ID: <20211025170242.GA395634@nvidia.com> (raw)
In-Reply-To: <72ede0f6dab61f7f23df9ac7a70666e07ef314b0.1635055496.git.leonro@nvidia.com>
On Sun, Oct 24, 2021 at 09:08:20AM +0300, Leon Romanovsky wrote:
> 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(-)
Applied to for-rc, thanks
Jason
next prev parent reply other threads:[~2021-10-25 17:04 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 ` [PATCH rdma-rc 1/2] RDMA/sa_query: Use strscpy_pad instead of memcpy to copy a string Leon Romanovsky
2021-10-25 17:02 ` Jason Gunthorpe [this message]
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=20211025170242.GA395634@nvidia.com \
--to=jgg@nvidia.com \
--cc=dledford@redhat.com \
--cc=ira.weiny@intel.com \
--cc=john.fleck@intel.com \
--cc=kaike.wan@intel.com \
--cc=leon@kernel.org \
--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.