linux-kernel - Re: [PATCH v2 1/1] uio.c: solve memory leak

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 8 Dec 2012 01:10:40 +0100
From:	"Hans J. Koch" <hjk@...sjkoch.de>
To:	Cong Ding <dinggnu@...il.com>
Cc:	"Hans J. Koch" <hjk@...sjkoch.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/1] uio.c: solve memory leak

On Fri, Dec 07, 2012 at 12:02:11AM +0100, Cong Ding wrote:
> ping Hans, did you have any comment on this?

Sounds right what you say. Is your patch v2 your final solution, or would
you like to come up with v3?

Thanks a lot for your patience and your thorough analysis.

Hans

> 
> - cong
> 
> On Fri, Nov 30, 2012 at 12:03 PM, Cong Ding <dinggnu@...il.com> wrote:
> > Hi Hans, I think the memory allocated with kzalloc is properly freed
> > by calling kobject_put.
> >
> > I can give a simple explanation.
> >
> > 1)  when we call kobject_init, the parameter portio_attr_type is
> > passed in. portio_attr_type includes a function pointer to
> > portio_release, which releases the memory of portio.
> >
> > 2) when we call kobject_put, kref_put is called with the pointer of
> > function kobject_release.
> > 3) kref_put calls kref_sub, with the same pointer of function kobject_release.
> > 4) and kref_put calls the function kboject_release if
> > atomic_sub_and_test returns true
> >
> > 5) let's look at what kobject_release is. it calls kobject_cleanup,
> > and kobject_cleanup calls t->release(kobj) where t->release is exactly
> > the function we passed in through portio_init at step (1). so function
> > portio_release is called, and the memory allocated with kzalloc is
> > freed.
> >
> > If there are anything wrong in my analysis, please feel free to let me know.
> >
> > Personally, I suggest to add a function to create and release
> > uio_portio, which is similar as kobject_create and kobject_put in file
> > lib/kobject.c. In this way, it avoid other readers thinking the memory
> > is not freed (and we should add some comments here). For example,
> > uio_portio_create call kzalloc and kboject_init, and returns
> > uio_portio, which is similar as function kobject_create; and
> > uio_portio_release calls kobject_put to release the memory. And we do
> > same thing for uio_map.
> >
> > The usage here is quite strange, but it works. If I write this
> > function from zero, I will use a pointer to kobject in uio_portio
> > struct instead of kobject struct itself. In this case I can call
> > kobject_create instead of kobject_init, and then we do both
> > kzalloc(uio_portio) and kfree(uio_portio) in the file uio.c.
> >
> > Best,
> > Cong
> >
> > On Fri, Nov 30, 2012 at 1:13 AM, Hans J. Koch <hjk@...sjkoch.de> wrote:
> >> There's still another bug: The memory allocated with kzalloc is
> >> never freed.
> 
--
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/