[PATCH] class: Free the kobject.name if kset_register fails

[PATCH] class: Free the kobject.name if kset_register fails

[Chen Lin Z]

Fix a memory leak by freeing the memory allocated in kobject_set_name
for the kobjet name.

unreferenced object 0xe2167700 (size 64):
  comm "swapper/0", pid 1, jiffies 4294938161 (age 90.540s)
  hex dump (first 32 bytes):
    6d 61 67 6e 65 74 69 63 00 11 c2 c0 1f e9 23 c1  magnetic......#.
    18 00 00 00 04 66 9b e4 e0 66 9b e4 94 76 16 e2  .....f...f...v..
  backtrace:
    [<c0fb49dc>] kmemleak_alloc+0x3c/0xa0
    [<c0936cb5>] __kmalloc_track_caller+0x115/0x1d0
    [<c0b6b753>] kvasprintf+0x33/0x60
    [<c0b5fae2>] kobject_set_name_vargs+0x22/0x60
    [<c0b5fb31>] kobject_set_name+0x11/0x20
    [<c0c1f93e>] __class_register+0x8e/0x1e0
    [<c0c1fadb>] __class_create+0x4b/0x70
    [<c1417d61>] mmc3524x_init+0x18/0x97
    [<c080046c>] do_one_initcall+0xbc/0x190
    [<c13e0b47>] kernel_init_freeable+0xea/0x18c
    [<c0fb2fd0>] kernel_init+0x10/0xe0
    [<c0fc3337>] ret_from_kernel_thread+0x1b/0x28
    [<ffffffff>] 0xffffffff

Signed-off-by: Chen Lin Z <lin.z.chen@intel.com>
---
 drivers/base/class.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/base/class.c b/drivers/base/class.c
index 6e81088..f6e7f53 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -200,6 +200,7 @@ int __class_register(struct class *cls, struct lock_class_key *key)
 
 	error = kset_register(&cp->subsys);
 	if (error) {
+		kfree(cp->subsys.kobj.name);
 		kfree(cp);
 		return error;
 	}
-- 
1.9.1

Re: [PATCH] class: Free the kobject.name if kset_register fails

[Greg KH]

On Mon, Jun 08, 2015 at 03:49:37PM +0800, Chen Lin Z wrote:
> Fix a memory leak by freeing the memory allocated in kobject_set_name
> for the kobjet name.
> 
> unreferenced object 0xe2167700 (size 64):
>   comm "swapper/0", pid 1, jiffies 4294938161 (age 90.540s)
>   hex dump (first 32 bytes):
>     6d 61 67 6e 65 74 69 63 00 11 c2 c0 1f e9 23 c1  magnetic......#.
>     18 00 00 00 04 66 9b e4 e0 66 9b e4 94 76 16 e2  .....f...f...v..
>   backtrace:
>     [<c0fb49dc>] kmemleak_alloc+0x3c/0xa0
>     [<c0936cb5>] __kmalloc_track_caller+0x115/0x1d0
>     [<c0b6b753>] kvasprintf+0x33/0x60
>     [<c0b5fae2>] kobject_set_name_vargs+0x22/0x60
>     [<c0b5fb31>] kobject_set_name+0x11/0x20
>     [<c0c1f93e>] __class_register+0x8e/0x1e0
>     [<c0c1fadb>] __class_create+0x4b/0x70
>     [<c1417d61>] mmc3524x_init+0x18/0x97
>     [<c080046c>] do_one_initcall+0xbc/0x190
>     [<c13e0b47>] kernel_init_freeable+0xea/0x18c
>     [<c0fb2fd0>] kernel_init+0x10/0xe0
>     [<c0fc3337>] ret_from_kernel_thread+0x1b/0x28
>     [<ffffffff>] 0xffffffff
> 
> Signed-off-by: Chen Lin Z <lin.z.chen@intel.com>
> ---
>  drivers/base/class.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/base/class.c b/drivers/base/class.c
> index 6e81088..f6e7f53 100644
> --- a/drivers/base/class.c
> +++ b/drivers/base/class.c
> @@ -200,6 +200,7 @@ int __class_register(struct class *cls, struct lock_class_key *key)
>  
>  	error = kset_register(&cp->subsys);
>  	if (error) {
> +		kfree(cp->subsys.kobj.name);

How did you ever trigger this error case?

I don't like mucking about in the root of the kobject name structure, as
who knows what is really happening there.  Isn't there some other
"better" way to resolve this?

thanks,

greg k-h

RE: [PATCH] class: Free the kobject.name if kset_register fails

[Chen, Lin Z]

Hi greg,

>How did you ever trigger this error case?
When try to register the same class twice.

>I don't like mucking about in the root of the kobject name structure, as who knows what is really happening there.  Isn't there some other "better" way to resolve this?
 I try to use below patch to fix issue,  but it'll cause double free issue and change code a lot if fix double free issue,  I think there is no better function which can be used to 
 free the kobject name.

diff --git a/lib/kobject.c b/lib/kobject.c
index cb14aea..a2711d1 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -794,8 +794,10 @@ int kset_register(struct kset *k)
 
        kset_init(k);
        err = kobject_add_internal(&k->kobj);
-       if (err)
+       if (err) {
+               kobject_put(&k->kobj);
                return err;
+       }

Thanks,

Lin


-----Original Message-----
From: Greg KH [mailto:gregkh@linuxfoundation.org] 
Sent: Tuesday, June 9, 2015 4:56 AM
To: Chen, Lin Z
Cc: linux-kernel@vger.kernel.org; He, Bo; yanmin_zhang@linux.intel.com
Subject: Re: [PATCH] class: Free the kobject.name if kset_register fails

On Mon, Jun 08, 2015 at 03:49:37PM +0800, Chen Lin Z wrote:
> Fix a memory leak by freeing the memory allocated in kobject_set_name 
> for the kobjet name.
> 
> unreferenced object 0xe2167700 (size 64):
>   comm "swapper/0", pid 1, jiffies 4294938161 (age 90.540s)
>   hex dump (first 32 bytes):
>     6d 61 67 6e 65 74 69 63 00 11 c2 c0 1f e9 23 c1  magnetic......#.
>     18 00 00 00 04 66 9b e4 e0 66 9b e4 94 76 16 e2  .....f...f...v..
>   backtrace:
>     [<c0fb49dc>] kmemleak_alloc+0x3c/0xa0
>     [<c0936cb5>] __kmalloc_track_caller+0x115/0x1d0
>     [<c0b6b753>] kvasprintf+0x33/0x60
>     [<c0b5fae2>] kobject_set_name_vargs+0x22/0x60
>     [<c0b5fb31>] kobject_set_name+0x11/0x20
>     [<c0c1f93e>] __class_register+0x8e/0x1e0
>     [<c0c1fadb>] __class_create+0x4b/0x70
>     [<c1417d61>] mmc3524x_init+0x18/0x97
>     [<c080046c>] do_one_initcall+0xbc/0x190
>     [<c13e0b47>] kernel_init_freeable+0xea/0x18c
>     [<c0fb2fd0>] kernel_init+0x10/0xe0
>     [<c0fc3337>] ret_from_kernel_thread+0x1b/0x28
>     [<ffffffff>] 0xffffffff
> 
> Signed-off-by: Chen Lin Z <lin.z.chen@intel.com>
> ---
>  drivers/base/class.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/base/class.c b/drivers/base/class.c index 
> 6e81088..f6e7f53 100644
> --- a/drivers/base/class.c
> +++ b/drivers/base/class.c
> @@ -200,6 +200,7 @@ int __class_register(struct class *cls, struct 
> lock_class_key *key)
>  
>  	error = kset_register(&cp->subsys);
>  	if (error) {
> +		kfree(cp->subsys.kobj.name);

How did you ever trigger this error case?

I don't like mucking about in the root of the kobject name structure, as who knows what is really happening there.  Isn't there some other "better" way to resolve this?

thanks,

greg k-h