netdev - Re: netfilter: active obj WARN when cleaning up

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]

Date:	Wed, 27 Nov 2013 15:34:15 -0800
From:	Greg KH <greg@...ah.com>
To:	Christoph Lameter <cl@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Pablo Neira Ayuso <pablo@...filter.org>,
	Sasha Levin <sasha.levin@...cle.com>,
	Patrick McHardy <kaber@...sh.net>, kadlec@...ckhole.kfki.hu,
	"David S. Miller" <davem@...emloft.net>,
	netfilter-devel@...r.kernel.org, coreteam@...filter.org,
	netdev@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <cl@...ux-foundation.org>
Subject: Re: netfilter: active obj WARN when cleaning up

On Wed, Nov 27, 2013 at 02:44:58PM +0100, Thomas Gleixner wrote:
> On Wed, 27 Nov 2013, Russell King - ARM Linux wrote:
> 
> > On Wed, Nov 27, 2013 at 01:32:31PM +0000, Russell King - ARM Linux wrote:
> > > On Wed, Nov 27, 2013 at 02:29:41PM +0100, Thomas Gleixner wrote:
> > > > Though the kobject is the only thing which has a delayed work embedded
> > > > inside struct kmem_cache. And the debug object splat points at the
> > > > kmem_cache_free() of the struct kmem_cache itself. That's why I
> > > > assumed the wreckage around that place. And indeed:
> > > > 
> > > > kmem_cache_destroy(s)
> > > >     __kmem_cache_shutdown(s)
> > > >       sysfs_slab_remove(s)
> > > >         ....
> > > > 	kobject_put(&s->kobj)
> > > >            kref_put(&kobj->kref, kobject_release);
> > > > 	     kobject_release(kref)
> > > >     	       #ifdef CONFIG_DEBUG_KOBJECT_RELEASE
> > > > 	         schedule_delayed_work(&kobj->release)
> > > > 	       #else
> > > > 	        kobject_cleanup(kobj)
> > > > 	       #endif
> > > > 
> > > > So in the CONFIG_DEBUG_KOBJECT_RELEASE=y case, schedule_delayed_work()
> > > > _IS_ called which arms the timer. debugobjects catches the attempt to
> > > > free struct kmem_cache which contains the armed timer.
> > > 
> > > You fail to show where the free is in the above path.
> > 
> > Right, there's a kmem_cache_free(kmem_cache, s); by the slob code
> > after the above sequence, which is The Bug(tm).
> > 
> > As I said, a kobject has its own lifetime.  If you embed that into
> > another structure, that structure inherits the lifetime of the kobject,
> > which is from the point at which it's created to the point at which the
> > kobject's release function is called.
> > 
> > So no, the code here is buggy.  The kobject debugging has yet again
> > found a violation of the kobject lifetime rules.  slub needs fixing.
> 
> I leave that discussion to you, greg and the slub folks.

/me grabs some popcorn from tglx

It's really not that much of a discussion, Documentation/kobject.txt has
said this for years, it's as if no one even reads documentation
anymore...

If you embed a kobject into a structure, you have to use the kobject for
the reference counting of the structure, otherwise it's a bug.  If you
don't want to use a kobject to reference count the structure, don't
embed it into it, use a pointer.

Are "slabs" never freed in the slub allocator?  Surely someone should
have seen the huge "this kobject doesn't have a release function" error
message that the kernel should have spit out for it?

Just make the kobject "dynamic" instead of embedded in struct kmem_cache
and all will be fine.  I can't believe this code has been broken for
this long.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html