From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH] xen-pciback: fix up cleanup path when alloc fails Date: Tue, 1 Dec 2015 16:34:53 -0500 Message-ID: <20151201213453.GA17283@char.us.oracle.com> References: <1448569959-7245-1-git-send-email-cardoe@cardoe.com> <20151201164717.GA5032@char.us.oracle.com> <20151201193517.GA32573@char.us.oracle.com> <565E0909.2010009@cardoe.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1a3sZl-0000aC-Jr for xen-devel@lists.xenproject.org; Tue, 01 Dec 2015 21:35:05 +0000 Content-Disposition: inline In-Reply-To: <565E0909.2010009@cardoe.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Doug Goldstein Cc: Wei Liu , Jonathan Creekmore , linux-kernel@vger.kernel.org, Paul Durrant , David Vrabel , xen-devel@lists.xenproject.org, Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On Tue, Dec 01, 2015 at 02:54:33PM -0600, Doug Goldstein wrote: > On 12/1/15 1:35 PM, Konrad Rzeszutek Wilk wrote: > > On Tue, Dec 01, 2015 at 11:47:17AM -0500, Konrad Rzeszutek Wilk wrote: > >> On Thu, Nov 26, 2015 at 02:32:39PM -0600, Doug Goldstein wrote: > >>> When allocating a pciback device fails, avoid the possibility of a > >>> use after free. > >> > >> Reviewed-by: Konrad Rzeszutek Wilk > >> > >> Ugh, and it looks like xen-blkfront has the same issue. > > > > Nope. No problems there. > > > > The ->probe if it fails (so xenbus_dev_probe returns the error) > > ends up in the 'probe_failed' label in really_probe which takes care by doing: > > > > dev_set_drvdata(dev, NULL); > > > > Wheew! > > > > either way the patch should go in, but the 'possibility' should > > be perhaps removed? Unless there is some other path I missed? > > I put 'possibility' in there because it will only happen when the > function returns failure. I was also trying to not make it sound panicky Right, but when it returns failure, the 'really_probe' will take care of setting dev_set_drvdata(dev, NULL) - so we won't have the use after free problem. > I guess. I can resubmit the patch with that word dropped if that's > desirable. Sure, or just say: "The 'really_probe' takes care of setting dev_set_drvdata(dev, NULL) in its failure path (which we would exercise if the ->probe function failed), so we we are OK. However lets be defensive as the code can change." > > > > >> > >>> > >>> Reported-by: Jonathan Creekmore > >>> Signed-off-by: Doug Goldstein > >>> --- > >>> drivers/xen/xen-pciback/xenbus.c | 4 +++- > >>> 1 file changed, 3 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/drivers/xen/xen-pciback/xenbus.c b/drivers/xen/xen-pciback/xenbus.c > >>> index 98bc345..4843741 100644 > >>> --- a/drivers/xen/xen-pciback/xenbus.c > >>> +++ b/drivers/xen/xen-pciback/xenbus.c > >>> @@ -44,7 +44,6 @@ static struct xen_pcibk_device *alloc_pdev(struct xenbus_device *xdev) > >>> dev_dbg(&xdev->dev, "allocated pdev @ 0x%p\n", pdev); > >>> > >>> pdev->xdev = xdev; > >>> - dev_set_drvdata(&xdev->dev, pdev); > >>> > >>> mutex_init(&pdev->dev_lock); > >>> > >>> @@ -58,6 +57,9 @@ static struct xen_pcibk_device *alloc_pdev(struct xenbus_device *xdev) > >>> kfree(pdev); > >>> pdev = NULL; > >>> } > >>> + > >>> + dev_set_drvdata(&xdev->dev, pdev); > >>> + > >>> out: > >>> return pdev; > >>> } > >>> -- > >>> 2.4.10 > >>> > > > -- > Doug Goldstein >