Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <1591210928.13983.24.camel@HansenPartnership.com>
Subject: Re: kobject_init_and_add is easy to misuse
From:   James Bottomley <James.Bottomley@HansenPartnership.com>
To:     Jason Gunthorpe <jgg@ziepe.ca>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Matthew Wilcox <willy@infradead.org>,
        Wang Hai <wanghai38@huawei.com>, cl@linux.com,
        penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com,
        akpm@linux-foundation.org, khlebnikov@yandex-team.ru,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org
Date:   Wed, 03 Jun 2020 12:02:08 -0700
In-Reply-To: <20200603183650.GI6578@ziepe.ca>
References: <20200602115033.1054-1-wanghai38@huawei.com>
         <20200602121035.GL19604@bombadil.infradead.org>
         <1591111514.4253.32.camel@HansenPartnership.com>
         <20200602173603.GB3579519@kroah.com>
         <1591127656.16819.7.camel@HansenPartnership.com>
         <20200602200756.GA3933938@kroah.com>
         <1591134670.16819.18.camel@HansenPartnership.com>
         <20200603002205.GE6578@ziepe.ca>
         <1591207475.4462.41.camel@HansenPartnership.com>
         <20200603183650.GI6578@ziepe.ca>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.

James