Thread (9 messages) 9 messages, 3 authors, 2018-07-11

Re: [PATCH 3/3] IB/srpt: Fix a use-after-free

From: "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Date: 2018-07-10 20:45:23
Also in: stable

On Tue, Jul 10, 2018 at 08:23:01PM +0000, Bart Van Assche wrote:
On Tue, 2018-07-10 at 20:51 +0200, Greg KH wrote:
quoted
On Tue, Jul 10, 2018 at 10:32:00AM -0700, Bart Van Assche wrote:
quoted
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
index 325bae29e90d..705f6a992d82 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -2152,6 +2152,7 @@ static int srpt_cm_req_recv(struct srpt_device *const sdev,
 	}
 
 	kref_init(&ch->kref);
+	kref_get(&ch->kref);
kref_init starts the reference count at at 1, so why do you need to
increment it right away?  That feels like something is "odd" here, why
do you start with 2 references in the same function?
Hi Greg,

An ib_srpt RDMA channel object (ch in the above code) must stay around as long
as the associated target core session (se_sess) exists and also as long as the
target core has not yet called srpt_close_session(). Hence the initialization of
ch->kref to 2 just before an RDMA channel is registered with the target core.
Shouldn't the registration increment the reference?  Starting out at "2"
feels very "odd", don't you agree?

thanks,

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help