[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211025170242.GA395634@nvidia.com>
Date: Mon, 25 Oct 2021 14:02:42 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Leon Romanovsky <leon@...nel.org>
Cc: Doug Ledford <dledford@...hat.com>,
Mark Zhang <markzhang@...dia.com>,
Ira Weiny <ira.weiny@...el.com>,
John Fleck <john.fleck@...el.com>,
Kaike Wan <kaike.wan@...el.com>, linux-kernel@...r.kernel.org,
linux-rdma@...r.kernel.org, Mark Bloch <markb@...lanox.com>,
Mark Bloch <mbloch@...dia.com>
Subject: Re: [PATCH rdma-rc 1/2] RDMA/sa_query: Use strscpy_pad instead of
memcpy to copy a string
On Sun, Oct 24, 2021 at 09:08:20AM +0300, Leon Romanovsky wrote:
> From: Mark Zhang <markzhang@...dia.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@...dia.com>
> Reviewed-by: Mark Bloch <mbloch@...dia.com>
> Signed-off-by: Leon Romanovsky <leonro@...dia.com>
> ---
> drivers/infiniband/core/sa_query.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Applied to for-rc, thanks
Jason
Powered by blists - more mailing lists