[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200603193013.GJ6578@ziepe.ca>
Date: Wed, 3 Jun 2020 16:30:13 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Matthew Wilcox <willy@...radead.org>,
Wang Hai <wanghai38@...wei.com>, cl@...ux.com,
penberg@...nel.org, rientjes@...gle.com, iamjoonsoo.kim@....com,
akpm@...ux-foundation.org, khlebnikov@...dex-team.ru,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: kobject_init_and_add is easy to misuse
On Wed, Jun 03, 2020 at 12:02:08PM -0700, James Bottomley wrote:
> On Wed, 2020-06-03 at 15:36 -0300, Jason Gunthorpe wrote:
> > 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().
>
> Well, if we have to go down the rabbit hole this far, it turns out to
> be fixable because of the state_in_sysfs flag:
>
> @@ -899,7 +903,8 @@ struct kobject *kset_find_obj(struct kset *kset, const char *name)
> spin_lock(&kset->list_lock);
>
> list_for_each_entry(k, &kset->list, entry) {
> - if (kobject_name(k) && !strcmp(kobject_name(k), name)) {
> + if (kobject_name(k) && k->state_in_sysfs &&
> + !strcmp(kobject_name(k), name)) {
> ret = kobject_get_unless_zero(k);
> break;
> }
>
> That would ensure the name can't be found until the sysfs directory
> creation has succeeded, which would be the point from which
> kobject_init_and_add() can't fail.
Convoluted, and needs something on the store of state_in_sysfs too,
but could work.
It feels more robust to stick with the put though..
Jason
Powered by blists - more mailing lists