linux-kernel - Re: kobject_init_and

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: <20200603183650.GI6578@ziepe.ca>
Date:   Wed, 3 Jun 2020 15:36:50 -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 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