linux-kernel - Re: [tpmdd-devel] [PATCH RFC v2 5/5] tpm2: expose resource manager via a device link /dev/tpms<n>

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: <20170113194730.GA32214@obsidianresearch.com>
Date:   Fri, 13 Jan 2017 12:47:30 -0700
From:   Jason Gunthorpe <jgunthorpe@...idianresearch.com>
To:     James Bottomley <James.Bottomley@...senPartnership.com>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        open list <linux-kernel@...r.kernel.org>,
        linux-security-module@...r.kernel.org,
        tpmdd-devel@...ts.sourceforge.net
Subject: Re: [tpmdd-devel] [PATCH RFC v2 5/5] tpm2: expose resource manager
 via a device link /dev/tpms<n>

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