Re: kobject_init_and_add is easy to misuse
From: Jason Gunthorpe
Date: Wed Jun 03 2020 - 14:36:55 EST
On Wed, Jun 03, 2020 at 11:04:35AM -0700, James Bottomley wrote:
> On Tue, 2020-06-02 at 21:22 -0300, Jason Gunthorpe wrote:
> > On Tue, Jun 02, 2020 at 02:51:10PM -0700, James Bottomley wrote:
> >
> > > My first thought was "what? I got suckered into creating a patch",
> > > thanks ;-) But now I look, all the error paths do unwind back to
> > > the initial state, so kfree() on error looks to be completely
> > > correct.
> >
> > It doesn't fully unwind if the kobject is put into a kset, then
> > another thread can get the kref during kset_find_obj() and kfree()
> > won't wait for the kref to go to 0. It must use put.
>
> That does seem a bit contrived: the only failure kobject_add_internal()
> can get after kobj_kset_join() is from directory creation. If
> directory creation fails, no name appears in sysfs and no event for the
> name is sent, how did another thread get the name to pass in to
> kset_find_obj()?
The other thread just guesses in a hostile way?
Eg it looks like the iommu stuff just feeds in user data to
kobj_kset_join().
Jason