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
_______________________________________________
tpmdd-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
