linux-kernel - Re: [PATCH 1/2] IB/sa: Resolving use-after-free in ib_nl_send

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b387f32b-c990-614b-c631-b38ddf821757@mellanox.com>
Date:   Thu, 7 May 2020 14:40:14 -0700
From:   Mark Bloch <markb@...lanox.com>
To:     "Wan, Kaike" <kaike.wan@...el.com>,
        Divya Indi <divya.indi@...cle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        Jason Gunthorpe <jgg@...pe.ca>
Cc:     Gerd Rausch <gerd.rausch@...cle.com>,
        Håkon Bugge <haakon.bugge@...cle.com>,
        Srinivas Eeda <srinivas.eeda@...cle.com>,
        Rama Nichanamatlu <rama.nichanamatlu@...cle.com>,
        Doug Ledford <dledford@...hat.com>
Subject: Re: [PATCH 1/2] IB/sa: Resolving use-after-free in ib_nl_send_msg.



On 5/7/2020 13:16, Wan, Kaike wrote:
> 
> 
>> -----Original Message-----
>> From: Mark Bloch <markb@...lanox.com>
>> Sent: Thursday, May 07, 2020 3:36 PM
>> To: Divya Indi <divya.indi@...cle.com>; linux-kernel@...r.kernel.org; linux-
>> rdma@...r.kernel.org; Jason Gunthorpe <jgg@...pe.ca>; Wan, Kaike
>> <kaike.wan@...el.com>
>> Cc: Gerd Rausch <gerd.rausch@...cle.com>; Håkon Bugge
>> <haakon.bugge@...cle.com>; Srinivas Eeda <srinivas.eeda@...cle.com>;
>> Rama Nichanamatlu <rama.nichanamatlu@...cle.com>; Doug Ledford
>> <dledford@...hat.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.

Mark
 
> 
> Kaike
>