RE: [PATCH 1/2] IB/sa: Resolving use-after-free in ib_nl_send_msg.

[Wan, Kaike]

> -----Original Message-----
> From: Mark Bloch <markb@xxxxxxxxxxxx>
> Sent: Thursday, May 07, 2020 3:36 PM
> To: Divya Indi <divya.indi@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; linux-
> rdma@xxxxxxxxxxxxxxx; Jason Gunthorpe <jgg@xxxxxxxx>; Wan, Kaike
> <kaike.wan@xxxxxxxxx>
> Cc: Gerd Rausch <gerd.rausch@xxxxxxxxxx>; HÃkon Bugge
> <haakon.bugge@xxxxxxxxxx>; Srinivas Eeda <srinivas.eeda@xxxxxxxxxx>;
> Rama Nichanamatlu <rama.nichanamatlu@xxxxxxxxxx>; Doug Ledford
> <dledford@xxxxxxxxxx>
> Subject: Re: [PATCH 1/2] IB/sa: Resolving use-after-free in ib_nl_send_msg.
> 
> 
> > @@ -1123,6 +1156,18 @@ int ib_nl_handle_resolve_resp(struct sk_buff
> > *skb,
> >
> >  	send_buf = query->mad_buf;
> >
> > +	/*
> > +	 * Make sure the IB_SA_NL_QUERY_SENT flag is set before
> > +	 * processing this query. If flag is not set, query can be accessed in
> > +	 * another context while setting the flag and processing the query
> will
> > +	 * eventually release it causing a possible use-after-free.
> > +	 */
> > +	if (unlikely(!ib_sa_nl_query_sent(query))) {
> 
> Can't there be a race here where you check the flag (it isn't set) and before
> you call wait_event() the flag is set and wake_up() is called which means you
> will wait here forever?

Should wait_event() catch that? That is,  if the flag is not set, wait_event() will sleep until the flag is set.

 or worse, a timeout will happen the query will be
> freed and them some other query will call wake_up() and we have again a
> use-after-free.

The request has been deleted from the request list by this time and therefore the timeout should have no impact here.


> 
> > +		spin_unlock_irqrestore(&ib_nl_request_lock, flags);
> > +		wait_event(wait_queue, ib_sa_nl_query_sent(query));
> 
> What if there are two queries sent to userspace, shouldn't you check and
> make sure you got woken up by the right one setting the flag?

The wait_event() is conditioned on the specific query (ib_sa_nl_query_sent(query)), not on the wait_queue itself.

> 
> Other than that, the entire solution makes it very complicated to reason with
> (flags set/checked without locking etc) maybe we should just revert and fix it
> the other way?

The flag could certainly be set under the lock, which may reduce complications. 

Kaike