Hi, Thanks for taking the time to review. Please find my comments inline -
On 5/7/20 1:16 PM, Wan, Kaike wrote: > >> -----Original Message----- >> From: Mark Bloch <[email protected]> >> Sent: Thursday, May 07, 2020 3:36 PM >> To: Divya Indi <[email protected]>; [email protected]; linux- >> [email protected]; Jason Gunthorpe <[email protected]>; Wan, Kaike >> <[email protected]> >> Cc: Gerd Rausch <[email protected]>; Håkon Bugge >> <[email protected]>; Srinivas Eeda <[email protected]>; >> Rama Nichanamatlu <[email protected]>; Doug Ledford >> <[email protected]> >> 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. We could use a lock or use atomic operations. However, the reason for not doing so was that we have 1 writer and multiple readers of the IB_SA_NL_QUERY_SENT flag and the readers wouldnt mind reading a stale value. Would it still be better to have a lock for this flag? Thanks, Divya > > Kaike >
