Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 1/2] IB/sa: Resolving use-after-free in ib_nl_send_msg.
To:     Mark Bloch <markb@mellanox.com>,
        "Wan, Kaike" <kaike.wan@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
        Jason Gunthorpe <jgg@ziepe.ca>
Cc:     Gerd Rausch <gerd.rausch@oracle.com>,
        =?UTF-8?Q?H=c3=a5kon_Bugge?= <haakon.bugge@oracle.com>,
        Srinivas Eeda <srinivas.eeda@oracle.com>,
        Rama Nichanamatlu <rama.nichanamatlu@oracle.com>,
        Doug Ledford <dledford@redhat.com>
References: <1588876487-5781-1-git-send-email-divya.indi@oracle.com>
 <1588876487-5781-2-git-send-email-divya.indi@oracle.com>
 <7572e503-312c-26a8-c8c2-05515f1c4f84@mellanox.com>
 <MW3PR11MB4665120FE43314C22A862324F4A50@MW3PR11MB4665.namprd11.prod.outlook.com>
 <b387f32b-c990-614b-c631-b38ddf821757@mellanox.com>
From:   Divya Indi <divya.indi@oracle.com>
Message-ID: <9cdcdf41-5ae9-dcac-d72a-77482ea6a59e@oracle.com>
Date:   Mon, 11 May 2020 14:10:59 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0)
 Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <b387f32b-c990-614b-c631-b38ddf821757@mellanox.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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 <markb@mellanox.com>
>>> Sent: Thursday, May 07, 2020 3:36 PM
>>> To: Divya Indi <divya.indi@oracle.com>; linux-kernel@vger.kernel.org; linux-
>>> rdma@vger.kernel.org; Jason Gunthorpe <jgg@ziepe.ca>; Wan, Kaike
>>> <kaike.wan@intel.com>
>>> Cc: Gerd Rausch <gerd.rausch@oracle.com>; Håkon Bugge
>>> <haakon.bugge@oracle.com>; Srinivas Eeda <srinivas.eeda@oracle.com>;
>>> Rama Nichanamatlu <rama.nichanamatlu@oracle.com>; Doug Ledford
>>> <dledford@redhat.com>
>>> 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