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: <MW3PR11MB4665C1835C792ADC4DFB9017F4BE0@MW3PR11MB4665.namprd11.prod.outlook.com>
Date:   Tue, 12 May 2020 11:15:12 +0000
From:   "Wan, Kaike" <kaike.wan@...el.com>
To:     Divya Indi <divya.indi@...cle.com>,
        Mark Bloch <markb@...lanox.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.



> -----Original Message-----
> From: Divya Indi <divya.indi@...cle.com>
> Sent: Monday, May 11, 2020 5:06 PM
> To: Wan, Kaike <kaike.wan@...el.com>; Mark Bloch
> <markb@...lanox.com>; linux-kernel@...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.
> 
> 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 <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.
> >
> >> 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?
> 

Yes. It will make the code less complicated and easier to maintain.

Kaike