On Wed, Mar 28, 2018 at 12:51:24PM -0600, Jason Gunthorpe wrote: > On Wed, Mar 28, 2018 at 09:34:21PM +0300, Leon Romanovsky wrote: > > On Wed, Mar 28, 2018 at 12:29:54PM -0600, Jason Gunthorpe wrote: > > > On Wed, Mar 28, 2018 at 09:22:25PM +0300, Leon Romanovsky wrote: > > > > > > > > rdma_addr_size(&ctx->cm_id->route.addr.dst_addr) is not user > > > > > input, it is part of the kernel state at this point. Right? > > > > > > > > > > Can rdma_addr_size even return 0 at this point? > > > > > > > > > > If yes, then we should return EINVAL, but that is to make the API sane > > > > > for the user not to protect the kernel. > > > > > > > > I'm not near code now, but from what I remember, the user can call to > > > > rdma_create_id(), it will create new ctx->cm_id but with addr zeroed, > > > > because ucma_alloc_ctx() uses kzalloc. > > > > > > > > After that this user will call it ucma_query() and will hit this flow. > > > > > > Okay, sure, but the memcpy(a,b,0) isn't going to trigger KASN.. > > > > I disagree with you, but it doesn't matter here. > > What do you mean disagree? Do actually know this triggers KASN or are > you just guessing? I performed a couple of experiments now and plain memcpy(..,0) doesn't generate any warnings. Thanks > > Jason
Attachment:
signature.asc
Description: PGP signature
