linux-kernel - Re: kobject ->k

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: <20071214214823.GA10305@kroah.com>
Date:	Fri, 14 Dec 2007 13:48:23 -0800
From:	Greg KH <greg@...ah.com>
To:	Greg KH <gregkh@...e.de>
Cc:	Alexey Dobriyan <adobriyan@...il.com>,
	Alexey Dobriyan <adobriyan@...ru>, akpm@...l.org,
	linux-kernel@...r.kernel.org, kay.sievers@...y.org
Subject: Re: kobject ->k_name memory leak

On Mon, Dec 03, 2007 at 01:25:51PM -0800, Greg KH wrote:
> On Tue, Dec 04, 2007 at 12:09:59AM +0300, Alexey Dobriyan wrote:
> > On Mon, Dec 03, 2007 at 12:47:16PM -0800, Greg KH wrote:
> > > On Mon, Dec 03, 2007 at 12:26:07PM +0300, Alexey Dobriyan wrote:
> > > > Hi, Greg!
> > > > 
> > > > Commit ce2c9cb0259acd2aed184499ebe41ab00da13b25 aka
> > > > "kobject: remove the static array for the name" introduced memory leak
> > > > of a module name after modprobe/rmmod. Apparently for modules ->release
> > > > callback is NULL.
> > > > 
> > > > kobject_cleanup: ->release = 00000000, name = 'foo_sysctl'
> > > > Pid: 1927, comm: rmmod Not tainted 2.6.24-rc3-e1cca7e8d484390169777b423a7fe46c7021fec1 #5
> > > >  [<c10d4a58>] kobject_cleanup+0xb8/0xc0
> > > >  [<c10d4a60>] kobject_release+0x0/0x10
> > > >  [<c10d587b>] kref_put+0x2b/0xa0
> > > >  [<c11dbe85>] _spin_unlock+0x25/0x40
> > > >  [<c1045b78>] free_module+0x78/0xd0
> > > >  [<c104773f>] sys_delete_module+0x12f/0x1a0
> > > 
> > > Hm, _which_ kobject associated with a module, there are 3 of them I
> > > think :)
> > 
> > Ouch!
> > 
> > > They should all have a release function, and if they do not, we think
> > > it's a "static" kobject and it is not safe to free that name.
> > > 
> > > I've been working on cleaning this up a lot in the -mm tree with over 80
> > > patches for the kset/kobject apis and interfaces.
> > > 
> > > But if we have a dynamic kobject, and we aren't freeing it properly,
> > > please let me know which one it is and I'll work to fix it for 2.6.24.
> > 
> > The one which is passed to kobject_set_name() in mod_sysfs_init()..
> 
> That one should be set to the module_ktype, which is in kernel/params.c,
> so the release function there should... oh crap, there is no release
> function.  That's a bug.  After I get out of meetings tonight I'll write
> up a patch for that, unless someone beats me to it :)

Ok, this is a mess.  We can't really have a release function for this
kobject, as the structure it is embedded it has it's own memory
management issues.

To fix this properly is going to take some major kobject/module surgery,
it's not a simple fix at all.  I'll tackle it for 2.6.25, as it fits in
nicely with the other kobject rework that I've already done in the -mm
tree.

So, for now, can we just live with this tiny memory leak on module
unload?

Or is the above trace something that users will see when unloading
modules?

thanks,

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