All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Lee Jones' <lee.jones@linaro.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Vlad Yasevich" <vyasevich@gmail.com>,
	Neil Horman <nhorman@tuxdriver.com>,
	"Marcelo Ricardo Leitner" <marcelo.leitner@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	lksctp developers <linux-sctp@vger.kernel.org>,
	"H.P. Yarroll" <piggy@acm.org>,
	Karl Knutson <karl@athena.chicago.il.us>,
	Jon Grimm <jgrimm@us.ibm.com>,
	Xingang Guo <xingang.guo@intel.com>,
	Hui Huang <hui.huang@nokia.com>,
	Sridhar Samudrala <sri@us.ibm.com>,
	Daisy Chang <daisyc@us.ibm.com>, Ryan Layer <rmlayer@us.ibm.com>,
	Kevin Gao <kevin.gao@intel.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH v2 1/2] sctp: export sctp_endpoint_{hold,put}() and return incremented endpoint
Date: Sun, 19 Dec 2021 14:04:08 +0000	[thread overview]
Message-ID: <20ea50c910654fa0abc601bbddc37eaf@AcuMS.aculab.com> (raw)
In-Reply-To: <YbygIz4oqlTkrQgD@google.com>

From: Lee Jones
> Sent: 17 December 2021 14:35
> 
> On Fri, 17 Dec 2021, David Laight wrote:
> 
> > From: Lee Jones
> > > Sent: 17 December 2021 13:46
> > >
> > > net/sctp/diag.c for instance is built into its own separate module
> > > (sctp_diag.ko) and requires the use of sctp_endpoint_{hold,put}() in
> > > order to prevent a recently found use-after-free issue.
> > >
> > > In order to prevent data corruption of the pointer used to take a
> > > reference on a specific endpoint, between the time of calling
> > > sctp_endpoint_hold() and it returning, the API now returns a pointer
> > > to the exact endpoint that was incremented.
> > >
> > > For example, in sctp_sock_dump(), we could have the following hunk:
> > >
> > > 	sctp_endpoint_hold(tsp->asoc->ep);
> > > 	ep = tsp->asoc->ep;
> > > 	sk = ep->base.sk
> > > 	lock_sock(ep->base.sk);
> > >
> > > It is possible for this task to be swapped out immediately following
> > > the call into sctp_endpoint_hold() that would change the address of
> > > tsp->asoc->ep to point to a completely different endpoint.  This means
> > > a reference could be taken to the old endpoint and the new one would
> > > be processed without a reference taken, moreover the new endpoint
> > > could then be freed whilst still processing as a result, causing a
> > > use-after-free.
> > >
> > > If we return the exact pointer that was held, we ensure this task
> > > processes only the endpoint we have taken a reference to.  The
> > > resultant hunk now looks like this:
> > >
> > > 	ep = sctp_endpoint_hold(tsp->asoc->ep);
> > > 	sk = ep->base.sk
> > > 	lock_sock(sk);
> >
> > Isn't that just the same as doing things in the other order?
> > 	ep = tsp->asoc->ep;
> > 	sctp_endpoint_hold(ep);
> 
> Sleep for a few milliseconds between those lines and see what happens.
> 
> 'ep' could still be freed between the assignment and the call.

It can also be freed half way through setting up the arguments to the call.
So any call:
		xxx(tsp->asoc->ep);
is only really valid if both tsp->asoc and asoc->ep are stable.
So it is exactly the same as doing:
		ep = tsp->asoc->ep;
		xxx(ep);
Returning the value of the argument doesn't help if any of the pointed-to
items can get freed.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2021-12-19 14:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-17 13:46 [PATCH v2 1/2] sctp: export sctp_endpoint_{hold,put}() and return incremented endpoint Lee Jones
2021-12-17 13:46 ` [PATCH v2 2/2] sctp: hold cached endpoints to prevent possible UAF Lee Jones
2021-12-17 14:17 ` [PATCH v2 1/2] sctp: export sctp_endpoint_{hold,put}() and return incremented endpoint David Laight
2021-12-17 14:35   ` Lee Jones
2021-12-19 14:04     ` David Laight [this message]
2021-12-17 15:06 ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20ea50c910654fa0abc601bbddc37eaf@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=daisyc@us.ibm.com \
    --cc=davem@davemloft.net \
    --cc=hui.huang@nokia.com \
    --cc=jgrimm@us.ibm.com \
    --cc=karl@athena.chicago.il.us \
    --cc=kevin.gao@intel.com \
    --cc=kuba@kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=marcelo.leitner@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=piggy@acm.org \
    --cc=rmlayer@us.ibm.com \
    --cc=sri@us.ibm.com \
    --cc=stable@vger.kernel.org \
    --cc=vyasevich@gmail.com \
    --cc=xingang.guo@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.