Hi Mark, Please find my comments inline -
On 5/7/20 2:40 PM, Mark Bloch wrote: > > On 5/7/2020 13:16, 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. > Right, missed that this macro is expends into some inline code. > > Looking at the code a little more, I think this also fixes another issue. > Lets say ib_nl_send_msg() returns an error but before we do the list_del() in > ib_nl_make_request() there is also a timeout, so in ib_nl_request_timeout() > we will do list_del() and then another one list_del() will be done in > ib_nl_make_request(). > >>> 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. > Anything that can help here with this. > For me in ib_nl_make_request() the comment should also explain that not only > ib_nl_handle_resolve_resp() > is waiting for the flag to be set but also ib_nl_request_timeout() and that a > timeout can't happen > before the flag is set. ib_nl_request_timeout() would re-queue the query to the request list if the flag is not set. However, makes sense! Noted, il add the comment in ib_nl_make_request to make things more clear. Thanks, Divya > Mark > >> Kaike >> i
