From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Gunthorpe Subject: Re: [PATCH RFC v2 5/5] tpm2: expose resource manager via a device link /dev/tpms Date: Fri, 13 Jan 2017 12:47:30 -0700 Message-ID: <20170113194730.GA32214@obsidianresearch.com> References: <20170112174612.9314-1-jarkko.sakkinen@linux.intel.com> <20170112174612.9314-6-jarkko.sakkinen@linux.intel.com> <20170112183919.GA12836@obsidianresearch.com> <1484335247.2527.28.camel@HansenPartnership.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1484335247.2527.28.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: James Bottomley Cc: linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, open list List-Id: tpmdd-devel@lists.sourceforge.net On Fri, Jan 13, 2017 at 11:20:47AM -0800, James Bottomley wrote: > On Thu, 2017-01-12 at 11:39 -0700, Jason Gunthorpe wrote: > > On Thu, Jan 12, 2017 at 07:46:08PM +0200, Jarkko Sakkinen wrote: > > > > > struct tpm_chip { > > > - struct device dev; > > > - struct cdev cdev; > > > + struct device dev, devrm; > > > > Hum.. devrm adds a new kref but doesn't do anything with the release > > function, so that is going to use after free, ie here: > > > > > put_device(&chip->dev); > > > + put_device(&chip->devrm); > > > return ERR_PTR(rc); > > > > And other places. > > > > One solution is to get_device(chip->dev) after > > device_initialize(dev->rm) and add a devrm->dev.release function to > > do put_device(chip->dev) > > Actually, no, the devrm is a completely lifetime managed device as part > of the chip structure. once you've done a device_del on it, it can be > kfreed because it's no longer visible to anything else. No, that isn't enough. Anything else could have obtained a kref on devrm outside of the sphere the device_del manages. For instance, the cdev does exactly that, via this: > chip->cdev.kobj.parent = &chip->dev.kobj; > + chip->cdevrm.kobj.parent = &chip->devrm.kobj; In the worst case the kref the cdev grabs is not released until after tpm_chip_unregister() returns. Having a kref that doesn't work is just asking for trouble, please make it work properly. Jason ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751132AbdAMTrn (ORCPT ); Fri, 13 Jan 2017 14:47:43 -0500 Received: from quartz.orcorp.ca ([184.70.90.242]:49364 "EHLO quartz.orcorp.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750914AbdAMTrl (ORCPT ); Fri, 13 Jan 2017 14:47:41 -0500 Date: Fri, 13 Jan 2017 12:47:30 -0700 From: Jason Gunthorpe To: James Bottomley Cc: Jarkko Sakkinen , open list , linux-security-module@vger.kernel.org, tpmdd-devel@lists.sourceforge.net Subject: Re: [tpmdd-devel] [PATCH RFC v2 5/5] tpm2: expose resource manager via a device link /dev/tpms Message-ID: <20170113194730.GA32214@obsidianresearch.com> References: <20170112174612.9314-1-jarkko.sakkinen@linux.intel.com> <20170112174612.9314-6-jarkko.sakkinen@linux.intel.com> <20170112183919.GA12836@obsidianresearch.com> <1484335247.2527.28.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1484335247.2527.28.camel@HansenPartnership.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Broken-Reverse-DNS: no host name found for IP address 10.0.0.156 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 13, 2017 at 11:20:47AM -0800, James Bottomley wrote: > On Thu, 2017-01-12 at 11:39 -0700, Jason Gunthorpe wrote: > > On Thu, Jan 12, 2017 at 07:46:08PM +0200, Jarkko Sakkinen wrote: > > > > > struct tpm_chip { > > > - struct device dev; > > > - struct cdev cdev; > > > + struct device dev, devrm; > > > > Hum.. devrm adds a new kref but doesn't do anything with the release > > function, so that is going to use after free, ie here: > > > > > put_device(&chip->dev); > > > + put_device(&chip->devrm); > > > return ERR_PTR(rc); > > > > And other places. > > > > One solution is to get_device(chip->dev) after > > device_initialize(dev->rm) and add a devrm->dev.release function to > > do put_device(chip->dev) > > Actually, no, the devrm is a completely lifetime managed device as part > of the chip structure. once you've done a device_del on it, it can be > kfreed because it's no longer visible to anything else. No, that isn't enough. Anything else could have obtained a kref on devrm outside of the sphere the device_del manages. For instance, the cdev does exactly that, via this: > chip->cdev.kobj.parent = &chip->dev.kobj; > + chip->cdevrm.kobj.parent = &chip->devrm.kobj; In the worst case the kref the cdev grabs is not released until after tpm_chip_unregister() returns. Having a kref that doesn't work is just asking for trouble, please make it work properly. Jason