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]

Message-ID: <alpine.DEB.2.02.1311271409280.30673@ionos.tec.linutronix.de>
Date:	Wed, 27 Nov 2013 14:29:41 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
cc:	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>,
	Greg KH <greg@...ah.com>
Subject: Re: netfilter: active obj WARN when cleaning up

On Wed, 27 Nov 2013, Russell King - ARM Linux wrote:
> On Wed, Nov 27, 2013 at 11:45:17AM +0100, Thomas Gleixner wrote:
> > On Wed, 27 Nov 2013, Pablo Neira Ayuso wrote:
> > 
> > > On Tue, Nov 26, 2013 at 02:11:57PM -0500, Sasha Levin wrote:
> > > > Ping? I still see this warning.
> > > 
> > > Did your test include patch 0c3c6c00c6?
> > 
> > And how is that patch supposed to help?
> >  
> > > > >[  418.312449] WARNING: CPU: 6 PID: 4178 at lib/debugobjects.c:260 debug_print_object+0x8d/0xb0()
> > > > >[  418.313243] ODEBUG: free active (active state 0) object type: timer_list hint:
> > > > >delayed_work_timer_fn+0x0/0x20
> > 
> > > > >[  418.321101]  [<ffffffff812874d7>] kmem_cache_free+0x197/0x340
> > > > >[  418.321101]  [<ffffffff81249e76>] kmem_cache_destroy+0x86/0xe0
> > > > >[  418.321101]  [<ffffffff83d5d681>] nf_conntrack_cleanup_net_list+0x131/0x170
> > 
> > The debug code detects an active timer, which itself is part of a
> > delayed work struct. The call comes from kmem_cache_destroy().
> > 
> >          kmem_cache_free(kmem_cache, s);
> > 
> > So debug object says: s contains an active timer. s is the kmem_cache
> > which is destroyed from nf_conntrack_cleanup_net_list.
> > 
> > Now struct kmem_cache has in case of SLUB:
> > 
> >     struct kobject kobj;    /* For sysfs */
> > 
> > and struct kobject has:
> > 
> > #ifdef CONFIG_DEBUG_KOBJECT_RELEASE
> >     struct delayed_work     release;
> > #endif
> > 
> > So this is the thing you want to look at:
> > 
> > commit c817a67ec (kobject: delayed kobject release: help find buggy
> > drivers) added that delayed work thing.
> > 
> > I fear that does not work for kobjects which are embedded into
> > something else.
> 
> No, kobjects embedded into something else have their lifetime determined
> by the embedded kobject.  That's rule #1 of kobjects - or rather reference
> counted objects.
> 
> The point at which the kobject gets destructed is when the release function
> is called.  If it is destructed before that time, that's a violation of
> the reference counted nature of kobjects, and that's what the delay on
> releasing is designed to catch.
> 
> It's designed to catch code which does this exact path:
> 
> 	put(obj)
> 	free(obj)
> 
> rather than code which does it the right way:
> 
> 	put(obj)
> 		-> refcount becomes 0
> 			-> release function gets called
> 				->free(obj)
> 
> The former is unsafe because obj may have other references.

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.

So much for rule #1

Thanks,

	tglx

--
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