[PATCH] ocfs2: possible memory leak in mlog_sys_init()

[PATCH] ocfs2: possible memory leak in mlog_sys_init()

[Yang Yingliang]

Inject fault while probing module, kset_register() may fail,
if it fails, but the refcount of kobject is not decreased to
0, the name allocated in kobject_set_name() is leaked. Fix
this by calling kset_put(), so that name can be freed in
callback function kobject_cleanup().

unreferenced object 0xffff888100da9348 (size 8):
  comm "modprobe", pid 257, jiffies 4294701096 (age 33.334s)
  hex dump (first 8 bytes):
    6c 6f 67 6d 61 73 6b 00                          logmask.
  backtrace:
    [<00000000306e441c>] __kmalloc_node_track_caller+0x44/0x1b0
    [<000000007c491a9e>] kstrdup+0x3a/0x70
    [<0000000015719a3b>] kstrdup_const+0x63/0x80
    [<0000000084e458ea>] kvasprintf_const+0x149/0x180
    [<0000000091302b42>] kobject_set_name_vargs+0x56/0x150
    [<000000005f48eeac>] kobject_set_name+0xab/0xe0

Fixes: 34980ca8faeb ("Drivers: clean up direct setting of the name of a kset")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
---
 fs/ocfs2/cluster/masklog.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
index 563881ddbf00..7f9ba816d955 100644
--- a/fs/ocfs2/cluster/masklog.c
+++ b/fs/ocfs2/cluster/masklog.c
@@ -156,6 +156,7 @@ static struct kset mlog_kset = {
 int mlog_sys_init(struct kset *o2cb_kset)
 {
 	int i = 0;
+	int ret;
 
 	while (mlog_attrs[i].attr.mode) {
 		mlog_default_attrs[i] = &mlog_attrs[i].attr;
@@ -165,7 +166,11 @@ int mlog_sys_init(struct kset *o2cb_kset)
 
 	kobject_set_name(&mlog_kset.kobj, "logmask");
 	mlog_kset.kobj.kset = o2cb_kset;
-	return kset_register(&mlog_kset);
+	ret = kset_register(&mlog_kset);
+	if (ret)
+		kset_put(&mlog_kset);
+
+	return ret;
 }
 
 void mlog_sys_shutdown(void)
-- 
2.25.1

Re: [PATCH] ocfs2: possible memory leak in mlog_sys_init()

[Joseph Qi]

Hi,

On 10/18/22 3:52 PM, Yang Yingliang wrote:
> Inject fault while probing module, kset_register() may fail,
> if it fails, but the refcount of kobject is not decreased to
> 0, the name allocated in kobject_set_name() is leaked. Fix
> this by calling kset_put(), so that name can be freed in
> callback function kobject_cleanup().
> 
> unreferenced object 0xffff888100da9348 (size 8):
>   comm "modprobe", pid 257, jiffies 4294701096 (age 33.334s)
>   hex dump (first 8 bytes):
>     6c 6f 67 6d 61 73 6b 00                          logmask.
>   backtrace:
>     [<00000000306e441c>] __kmalloc_node_track_caller+0x44/0x1b0
>     [<000000007c491a9e>] kstrdup+0x3a/0x70
>     [<0000000015719a3b>] kstrdup_const+0x63/0x80
>     [<0000000084e458ea>] kvasprintf_const+0x149/0x180
>     [<0000000091302b42>] kobject_set_name_vargs+0x56/0x150
>     [<000000005f48eeac>] kobject_set_name+0xab/0xe0
> 
> Fixes: 34980ca8faeb ("Drivers: clean up direct setting of the name of a kset")
> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
> ---
>  fs/ocfs2/cluster/masklog.c | 7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
> index 563881ddbf00..7f9ba816d955 100644
> --- a/fs/ocfs2/cluster/masklog.c
> +++ b/fs/ocfs2/cluster/masklog.c
> @@ -156,6 +156,7 @@ static struct kset mlog_kset = {
>  int mlog_sys_init(struct kset *o2cb_kset)
>  {
>  	int i = 0;
> +	int ret;
>  
>  	while (mlog_attrs[i].attr.mode) {
>  		mlog_default_attrs[i] = &mlog_attrs[i].attr;
> @@ -165,7 +166,11 @@ int mlog_sys_init(struct kset *o2cb_kset)
>  
>  	kobject_set_name(&mlog_kset.kobj, "logmask");
>  	mlog_kset.kobj.kset = o2cb_kset;
> -	return kset_register(&mlog_kset);
> +	ret = kset_register(&mlog_kset);

If register fails, it will call unregister in o2cb_sys_init(), which
will put kobject.

Thanks,
Joseph

> +	if (ret)
> +		kset_put(&mlog_kset);
> +
> +	return ret;
>  }
>  
>  void mlog_sys_shutdown(void)

Re: [PATCH] ocfs2: possible memory leak in mlog_sys_init()

[Yang Yingliang]

Hi,

On 2022/10/18 17:02, Joseph Qi wrote:
> Hi,
>
> On 10/18/22 3:52 PM, Yang Yingliang wrote:
>> Inject fault while probing module, kset_register() may fail,
>> if it fails, but the refcount of kobject is not decreased to
>> 0, the name allocated in kobject_set_name() is leaked. Fix
>> this by calling kset_put(), so that name can be freed in
>> callback function kobject_cleanup().
>>
>> unreferenced object 0xffff888100da9348 (size 8):
>>    comm "modprobe", pid 257, jiffies 4294701096 (age 33.334s)
>>    hex dump (first 8 bytes):
>>      6c 6f 67 6d 61 73 6b 00                          logmask.
>>    backtrace:
>>      [<00000000306e441c>] __kmalloc_node_track_caller+0x44/0x1b0
>>      [<000000007c491a9e>] kstrdup+0x3a/0x70
>>      [<0000000015719a3b>] kstrdup_const+0x63/0x80
>>      [<0000000084e458ea>] kvasprintf_const+0x149/0x180
>>      [<0000000091302b42>] kobject_set_name_vargs+0x56/0x150
>>      [<000000005f48eeac>] kobject_set_name+0xab/0xe0
>>
>> Fixes: 34980ca8faeb ("Drivers: clean up direct setting of the name of a kset")
>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
>> ---
>>   fs/ocfs2/cluster/masklog.c | 7 ++++++-
>>   1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
>> index 563881ddbf00..7f9ba816d955 100644
>> --- a/fs/ocfs2/cluster/masklog.c
>> +++ b/fs/ocfs2/cluster/masklog.c
>> @@ -156,6 +156,7 @@ static struct kset mlog_kset = {
>>   int mlog_sys_init(struct kset *o2cb_kset)
>>   {
>>   	int i = 0;
>> +	int ret;
>>   
>>   	while (mlog_attrs[i].attr.mode) {
>>   		mlog_default_attrs[i] = &mlog_attrs[i].attr;
>> @@ -165,7 +166,11 @@ int mlog_sys_init(struct kset *o2cb_kset)
>>   
>>   	kobject_set_name(&mlog_kset.kobj, "logmask");
>>   	mlog_kset.kobj.kset = o2cb_kset;
>> -	return kset_register(&mlog_kset);
>> +	ret = kset_register(&mlog_kset);
> If register fails, it will call unregister in o2cb_sys_init(), which
> will put kobject.
They are different ksets, the kset unregistered in o2cb_sys_init() is 
'o2cb_kset', the
kset used to registered in mlog_sys_init() is 'mlog_kset', and they hold 
difference
refcounts.

Thanks,
Yang
>
> Thanks,
> Joseph
>
>> +	if (ret)
>> +		kset_put(&mlog_kset);
>> +
>> +	return ret;
>>   }
>>   
>>   void mlog_sys_shutdown(void)
> .

Re: [PATCH] ocfs2: possible memory leak in mlog_sys_init()

[Joseph Qi]

On 10/18/22 6:33 PM, Yang Yingliang wrote:
> Hi,
> 
> On 2022/10/18 17:02, Joseph Qi wrote:
>> Hi,
>>
>> On 10/18/22 3:52 PM, Yang Yingliang wrote:
>>> Inject fault while probing module, kset_register() may fail,
>>> if it fails, but the refcount of kobject is not decreased to
>>> 0, the name allocated in kobject_set_name() is leaked. Fix
>>> this by calling kset_put(), so that name can be freed in
>>> callback function kobject_cleanup().
>>>
>>> unreferenced object 0xffff888100da9348 (size 8):
>>>    comm "modprobe", pid 257, jiffies 4294701096 (age 33.334s)
>>>    hex dump (first 8 bytes):
>>>      6c 6f 67 6d 61 73 6b 00                          logmask.
>>>    backtrace:
>>>      [<00000000306e441c>] __kmalloc_node_track_caller+0x44/0x1b0
>>>      [<000000007c491a9e>] kstrdup+0x3a/0x70
>>>      [<0000000015719a3b>] kstrdup_const+0x63/0x80
>>>      [<0000000084e458ea>] kvasprintf_const+0x149/0x180
>>>      [<0000000091302b42>] kobject_set_name_vargs+0x56/0x150
>>>      [<000000005f48eeac>] kobject_set_name+0xab/0xe0
>>>
>>> Fixes: 34980ca8faeb ("Drivers: clean up direct setting of the name of a kset")
>>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
>>> ---
>>>   fs/ocfs2/cluster/masklog.c | 7 ++++++-
>>>   1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
>>> index 563881ddbf00..7f9ba816d955 100644
>>> --- a/fs/ocfs2/cluster/masklog.c
>>> +++ b/fs/ocfs2/cluster/masklog.c
>>> @@ -156,6 +156,7 @@ static struct kset mlog_kset = {
>>>   int mlog_sys_init(struct kset *o2cb_kset)
>>>   {
>>>       int i = 0;
>>> +    int ret;
>>>         while (mlog_attrs[i].attr.mode) {
>>>           mlog_default_attrs[i] = &mlog_attrs[i].attr;
>>> @@ -165,7 +166,11 @@ int mlog_sys_init(struct kset *o2cb_kset)
>>>         kobject_set_name(&mlog_kset.kobj, "logmask");
>>>       mlog_kset.kobj.kset = o2cb_kset;
>>> -    return kset_register(&mlog_kset);
>>> +    ret = kset_register(&mlog_kset);
>> If register fails, it will call unregister in o2cb_sys_init(), which
>> will put kobject.
> They are different ksets, the kset unregistered in o2cb_sys_init() is 'o2cb_kset', the
> kset used to registered in mlog_sys_init() is 'mlog_kset', and they hold difference
> refcounts.
> Yes, you are right. I've mixed the two ksets up.
In theory, kset_register() may return error because of a NULL kset, so
here we may not call kset_put() directly, I'm not sure if a static
checker will happy.
Though this can't happen since it's already statically allocated...

Thanks,
Joseph

Re: [PATCH] ocfs2: possible memory leak in mlog_sys_init()

[Yang Yingliang]

On 2022/10/18 21:39, Joseph Qi wrote:
>
> On 10/18/22 6:33 PM, Yang Yingliang wrote:
>> Hi,
>>
>> On 2022/10/18 17:02, Joseph Qi wrote:
>>> Hi,
>>>
>>> On 10/18/22 3:52 PM, Yang Yingliang wrote:
>>>> Inject fault while probing module, kset_register() may fail,
>>>> if it fails, but the refcount of kobject is not decreased to
>>>> 0, the name allocated in kobject_set_name() is leaked. Fix
>>>> this by calling kset_put(), so that name can be freed in
>>>> callback function kobject_cleanup().
>>>>
>>>> unreferenced object 0xffff888100da9348 (size 8):
>>>>     comm "modprobe", pid 257, jiffies 4294701096 (age 33.334s)
>>>>     hex dump (first 8 bytes):
>>>>       6c 6f 67 6d 61 73 6b 00                          logmask.
>>>>     backtrace:
>>>>       [<00000000306e441c>] __kmalloc_node_track_caller+0x44/0x1b0
>>>>       [<000000007c491a9e>] kstrdup+0x3a/0x70
>>>>       [<0000000015719a3b>] kstrdup_const+0x63/0x80
>>>>       [<0000000084e458ea>] kvasprintf_const+0x149/0x180
>>>>       [<0000000091302b42>] kobject_set_name_vargs+0x56/0x150
>>>>       [<000000005f48eeac>] kobject_set_name+0xab/0xe0
>>>>
>>>> Fixes: 34980ca8faeb ("Drivers: clean up direct setting of the name of a kset")
>>>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
>>>> ---
>>>>    fs/ocfs2/cluster/masklog.c | 7 ++++++-
>>>>    1 file changed, 6 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
>>>> index 563881ddbf00..7f9ba816d955 100644
>>>> --- a/fs/ocfs2/cluster/masklog.c
>>>> +++ b/fs/ocfs2/cluster/masklog.c
>>>> @@ -156,6 +156,7 @@ static struct kset mlog_kset = {
>>>>    int mlog_sys_init(struct kset *o2cb_kset)
>>>>    {
>>>>        int i = 0;
>>>> +    int ret;
>>>>          while (mlog_attrs[i].attr.mode) {
>>>>            mlog_default_attrs[i] = &mlog_attrs[i].attr;
>>>> @@ -165,7 +166,11 @@ int mlog_sys_init(struct kset *o2cb_kset)
>>>>          kobject_set_name(&mlog_kset.kobj, "logmask");
>>>>        mlog_kset.kobj.kset = o2cb_kset;
>>>> -    return kset_register(&mlog_kset);
>>>> +    ret = kset_register(&mlog_kset);
>>> If register fails, it will call unregister in o2cb_sys_init(), which
>>> will put kobject.
>> They are different ksets, the kset unregistered in o2cb_sys_init() is 'o2cb_kset', the
>> kset used to registered in mlog_sys_init() is 'mlog_kset', and they hold difference
>> refcounts.
>> Yes, you are right. I've mixed the two ksets up.
> In theory, kset_register() may return error because of a NULL kset, so
> here we may not call kset_put() directly, I'm not sure if a static
> checker will happy.
> Though this can't happen since it's already statically allocated...
kset_register() may fail if kobject_add_internal() return error (can't 
allocate memory), the name
"logmask" is dynamically alloctated while ocfs2 is compile as module and 
insert it (if ocfs2 is
built in kernel, the name is constant, it won't cause a leak), so the 
name can be leaked.

Thanks,
Yang
>
> Thanks,
> Joseph
>
> .

Re: [PATCH] ocfs2: possible memory leak in mlog_sys_init()

[Joseph Qi]

On 10/18/22 10:28 PM, Yang Yingliang wrote:
> 
> On 2022/10/18 21:39, Joseph Qi wrote:
>>
>> On 10/18/22 6:33 PM, Yang Yingliang wrote:
>>> Hi,
>>>
>>> On 2022/10/18 17:02, Joseph Qi wrote:
>>>> Hi,
>>>>
>>>> On 10/18/22 3:52 PM, Yang Yingliang wrote:
>>>>> Inject fault while probing module, kset_register() may fail,
>>>>> if it fails, but the refcount of kobject is not decreased to
>>>>> 0, the name allocated in kobject_set_name() is leaked. Fix
>>>>> this by calling kset_put(), so that name can be freed in
>>>>> callback function kobject_cleanup().
>>>>>
>>>>> unreferenced object 0xffff888100da9348 (size 8):
>>>>>     comm "modprobe", pid 257, jiffies 4294701096 (age 33.334s)
>>>>>     hex dump (first 8 bytes):
>>>>>       6c 6f 67 6d 61 73 6b 00                          logmask.
>>>>>     backtrace:
>>>>>       [<00000000306e441c>] __kmalloc_node_track_caller+0x44/0x1b0
>>>>>       [<000000007c491a9e>] kstrdup+0x3a/0x70
>>>>>       [<0000000015719a3b>] kstrdup_const+0x63/0x80
>>>>>       [<0000000084e458ea>] kvasprintf_const+0x149/0x180
>>>>>       [<0000000091302b42>] kobject_set_name_vargs+0x56/0x150
>>>>>       [<000000005f48eeac>] kobject_set_name+0xab/0xe0
>>>>>
>>>>> Fixes: 34980ca8faeb ("Drivers: clean up direct setting of the name of a kset")
>>>>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
>>>>> ---
>>>>>    fs/ocfs2/cluster/masklog.c | 7 ++++++-
>>>>>    1 file changed, 6 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
>>>>> index 563881ddbf00..7f9ba816d955 100644
>>>>> --- a/fs/ocfs2/cluster/masklog.c
>>>>> +++ b/fs/ocfs2/cluster/masklog.c
>>>>> @@ -156,6 +156,7 @@ static struct kset mlog_kset = {
>>>>>    int mlog_sys_init(struct kset *o2cb_kset)
>>>>>    {
>>>>>        int i = 0;
>>>>> +    int ret;
>>>>>          while (mlog_attrs[i].attr.mode) {
>>>>>            mlog_default_attrs[i] = &mlog_attrs[i].attr;
>>>>> @@ -165,7 +166,11 @@ int mlog_sys_init(struct kset *o2cb_kset)
>>>>>          kobject_set_name(&mlog_kset.kobj, "logmask");
>>>>>        mlog_kset.kobj.kset = o2cb_kset;
>>>>> -    return kset_register(&mlog_kset);
>>>>> +    ret = kset_register(&mlog_kset);
>>>> If register fails, it will call unregister in o2cb_sys_init(), which
>>>> will put kobject.
>>> They are different ksets, the kset unregistered in o2cb_sys_init() is 'o2cb_kset', the
>>> kset used to registered in mlog_sys_init() is 'mlog_kset', and they hold difference
>>> refcounts.
>>> Yes, you are right. I've mixed the two ksets up.
>> In theory, kset_register() may return error because of a NULL kset, so
>> here we may not call kset_put() directly, I'm not sure if a static
>> checker will happy.
>> Though this can't happen since it's already statically allocated...
> kset_register() may fail if kobject_add_internal() return error (can't allocate memory), the name
> "logmask" is dynamically alloctated while ocfs2 is compile as module and insert it (if ocfs2 is
> built in kernel, the name is constant, it won't cause a leak), so the name can be leaked.

What I mean is kset_register() may fail with many reasons, or even
without kset_init().
I wonder if we have to handle this internal kset_register(), but not
leave it to caller. This may benefit other callers as well.

Something like:
err = kobject_add_internal(&k->kobj);
if (err) {
	kset_put(k);
	return err;
}

Thanks,
Joseph

Re: [PATCH] ocfs2: possible memory leak in mlog_sys_init()

[Yang Yingliang]

On 2022/10/19 10:26, Joseph Qi wrote:
>
> On 10/18/22 10:28 PM, Yang Yingliang wrote:
>> On 2022/10/18 21:39, Joseph Qi wrote:
>>> On 10/18/22 6:33 PM, Yang Yingliang wrote:
>>>> Hi,
>>>>
>>>> On 2022/10/18 17:02, Joseph Qi wrote:
>>>>> Hi,
>>>>>
>>>>> On 10/18/22 3:52 PM, Yang Yingliang wrote:
>>>>>> Inject fault while probing module, kset_register() may fail,
>>>>>> if it fails, but the refcount of kobject is not decreased to
>>>>>> 0, the name allocated in kobject_set_name() is leaked. Fix
>>>>>> this by calling kset_put(), so that name can be freed in
>>>>>> callback function kobject_cleanup().
>>>>>>
>>>>>> unreferenced object 0xffff888100da9348 (size 8):
>>>>>>      comm "modprobe", pid 257, jiffies 4294701096 (age 33.334s)
>>>>>>      hex dump (first 8 bytes):
>>>>>>        6c 6f 67 6d 61 73 6b 00                          logmask.
>>>>>>      backtrace:
>>>>>>        [<00000000306e441c>] __kmalloc_node_track_caller+0x44/0x1b0
>>>>>>        [<000000007c491a9e>] kstrdup+0x3a/0x70
>>>>>>        [<0000000015719a3b>] kstrdup_const+0x63/0x80
>>>>>>        [<0000000084e458ea>] kvasprintf_const+0x149/0x180
>>>>>>        [<0000000091302b42>] kobject_set_name_vargs+0x56/0x150
>>>>>>        [<000000005f48eeac>] kobject_set_name+0xab/0xe0
>>>>>>
>>>>>> Fixes: 34980ca8faeb ("Drivers: clean up direct setting of the name of a kset")
>>>>>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
>>>>>> ---
>>>>>>     fs/ocfs2/cluster/masklog.c | 7 ++++++-
>>>>>>     1 file changed, 6 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
>>>>>> index 563881ddbf00..7f9ba816d955 100644
>>>>>> --- a/fs/ocfs2/cluster/masklog.c
>>>>>> +++ b/fs/ocfs2/cluster/masklog.c
>>>>>> @@ -156,6 +156,7 @@ static struct kset mlog_kset = {
>>>>>>     int mlog_sys_init(struct kset *o2cb_kset)
>>>>>>     {
>>>>>>         int i = 0;
>>>>>> +    int ret;
>>>>>>           while (mlog_attrs[i].attr.mode) {
>>>>>>             mlog_default_attrs[i] = &mlog_attrs[i].attr;
>>>>>> @@ -165,7 +166,11 @@ int mlog_sys_init(struct kset *o2cb_kset)
>>>>>>           kobject_set_name(&mlog_kset.kobj, "logmask");
>>>>>>         mlog_kset.kobj.kset = o2cb_kset;
>>>>>> -    return kset_register(&mlog_kset);
>>>>>> +    ret = kset_register(&mlog_kset);
>>>>> If register fails, it will call unregister in o2cb_sys_init(), which
>>>>> will put kobject.
>>>> They are different ksets, the kset unregistered in o2cb_sys_init() is 'o2cb_kset', the
>>>> kset used to registered in mlog_sys_init() is 'mlog_kset', and they hold difference
>>>> refcounts.
>>>> Yes, you are right. I've mixed the two ksets up.
>>> In theory, kset_register() may return error because of a NULL kset, so
>>> here we may not call kset_put() directly, I'm not sure if a static
>>> checker will happy.
>>> Though this can't happen since it's already statically allocated...
>> kset_register() may fail if kobject_add_internal() return error (can't allocate memory), the name
>> "logmask" is dynamically alloctated while ocfs2 is compile as module and insert it (if ocfs2 is
>> built in kernel, the name is constant, it won't cause a leak), so the name can be leaked.
> What I mean is kset_register() may fail with many reasons, or even
> without kset_init().
> I wonder if we have to handle this internal kset_register(), but not
> leave it to caller. This may benefit other callers as well.
>
> Something like:
> err = kobject_add_internal(&k->kobj);
> if (err) {
> 	kset_put(k);
> 	return err;
> }
I had think about this method to fix this, but some kset is allocated 
dynamically in driver and
it's freed in callback function which is called after kset_put() and in 
error path in driver will free
it again, it leads double free in some drivers.

I think kset_register() is similar with device_register(), if it fails 
need another put function to give
up reference in driver.

Thanks,
Yang
>
> Thanks,
> Joseph
>
> .

Re: [PATCH] ocfs2: possible memory leak in mlog_sys_init()

[Joseph Qi]

On 10/19/22 10:57 AM, Yang Yingliang wrote:
> 
> On 2022/10/19 10:26, Joseph Qi wrote:
>>
>> On 10/18/22 10:28 PM, Yang Yingliang wrote:
>>> On 2022/10/18 21:39, Joseph Qi wrote:
>>>> On 10/18/22 6:33 PM, Yang Yingliang wrote:
>>>>> Hi,
>>>>>
>>>>> On 2022/10/18 17:02, Joseph Qi wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 10/18/22 3:52 PM, Yang Yingliang wrote:
>>>>>>> Inject fault while probing module, kset_register() may fail,
>>>>>>> if it fails, but the refcount of kobject is not decreased to
>>>>>>> 0, the name allocated in kobject_set_name() is leaked. Fix
>>>>>>> this by calling kset_put(), so that name can be freed in
>>>>>>> callback function kobject_cleanup().
>>>>>>>
>>>>>>> unreferenced object 0xffff888100da9348 (size 8):
>>>>>>>      comm "modprobe", pid 257, jiffies 4294701096 (age 33.334s)
>>>>>>>      hex dump (first 8 bytes):
>>>>>>>        6c 6f 67 6d 61 73 6b 00                          logmask.
>>>>>>>      backtrace:
>>>>>>>        [<00000000306e441c>] __kmalloc_node_track_caller+0x44/0x1b0
>>>>>>>        [<000000007c491a9e>] kstrdup+0x3a/0x70
>>>>>>>        [<0000000015719a3b>] kstrdup_const+0x63/0x80
>>>>>>>        [<0000000084e458ea>] kvasprintf_const+0x149/0x180
>>>>>>>        [<0000000091302b42>] kobject_set_name_vargs+0x56/0x150
>>>>>>>        [<000000005f48eeac>] kobject_set_name+0xab/0xe0
>>>>>>>
>>>>>>> Fixes: 34980ca8faeb ("Drivers: clean up direct setting of the name of a kset")
>>>>>>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
>>>>>>> ---
>>>>>>>     fs/ocfs2/cluster/masklog.c | 7 ++++++-
>>>>>>>     1 file changed, 6 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
>>>>>>> index 563881ddbf00..7f9ba816d955 100644
>>>>>>> --- a/fs/ocfs2/cluster/masklog.c
>>>>>>> +++ b/fs/ocfs2/cluster/masklog.c
>>>>>>> @@ -156,6 +156,7 @@ static struct kset mlog_kset = {
>>>>>>>     int mlog_sys_init(struct kset *o2cb_kset)
>>>>>>>     {
>>>>>>>         int i = 0;
>>>>>>> +    int ret;
>>>>>>>           while (mlog_attrs[i].attr.mode) {
>>>>>>>             mlog_default_attrs[i] = &mlog_attrs[i].attr;
>>>>>>> @@ -165,7 +166,11 @@ int mlog_sys_init(struct kset *o2cb_kset)
>>>>>>>           kobject_set_name(&mlog_kset.kobj, "logmask");
>>>>>>>         mlog_kset.kobj.kset = o2cb_kset;
>>>>>>> -    return kset_register(&mlog_kset);
>>>>>>> +    ret = kset_register(&mlog_kset);
>>>>>> If register fails, it will call unregister in o2cb_sys_init(), which
>>>>>> will put kobject.
>>>>> They are different ksets, the kset unregistered in o2cb_sys_init() is 'o2cb_kset', the
>>>>> kset used to registered in mlog_sys_init() is 'mlog_kset', and they hold difference
>>>>> refcounts.
>>>>> Yes, you are right. I've mixed the two ksets up.
>>>> In theory, kset_register() may return error because of a NULL kset, so
>>>> here we may not call kset_put() directly, I'm not sure if a static
>>>> checker will happy.
>>>> Though this can't happen since it's already statically allocated...
>>> kset_register() may fail if kobject_add_internal() return error (can't allocate memory), the name
>>> "logmask" is dynamically alloctated while ocfs2 is compile as module and insert it (if ocfs2 is
>>> built in kernel, the name is constant, it won't cause a leak), so the name can be leaked.
>> What I mean is kset_register() may fail with many reasons, or even
>> without kset_init().
>> I wonder if we have to handle this internal kset_register(), but not
>> leave it to caller. This may benefit other callers as well.
>>
>> Something like:
>> err = kobject_add_internal(&k->kobj);
>> if (err) {
>>     kset_put(k);
>>     return err;
>> }
> I had think about this method to fix this, but some kset is allocated dynamically in driver and
> it's freed in callback function which is called after kset_put() and in error path in driver will free
> it again, it leads double free in some drivers.
> 
I don't think it's good idea that caller has to take care part of the
internal logic of kset_register() in case of error.
Hi Greg, what do you think?

Thanks,
Joseph

> I think kset_register() is similar with device_register(), if it fails need another put function to give
> up reference in driver.
> 

Re: [PATCH] ocfs2: possible memory leak in mlog_sys_init()

[Greg Kroah-Hartman]

On Thu, Oct 20, 2022 at 10:06:48AM +0800, Joseph Qi wrote:
> 
> 
> On 10/19/22 10:57 AM, Yang Yingliang wrote:
> > 
> > On 2022/10/19 10:26, Joseph Qi wrote:
> >>
> >> On 10/18/22 10:28 PM, Yang Yingliang wrote:
> >>> On 2022/10/18 21:39, Joseph Qi wrote:
> >>>> On 10/18/22 6:33 PM, Yang Yingliang wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On 2022/10/18 17:02, Joseph Qi wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> On 10/18/22 3:52 PM, Yang Yingliang wrote:
> >>>>>>> Inject fault while probing module, kset_register() may fail,
> >>>>>>> if it fails, but the refcount of kobject is not decreased to
> >>>>>>> 0, the name allocated in kobject_set_name() is leaked. Fix
> >>>>>>> this by calling kset_put(), so that name can be freed in
> >>>>>>> callback function kobject_cleanup().
> >>>>>>>
> >>>>>>> unreferenced object 0xffff888100da9348 (size 8):
> >>>>>>>      comm "modprobe", pid 257, jiffies 4294701096 (age 33.334s)
> >>>>>>>      hex dump (first 8 bytes):
> >>>>>>>        6c 6f 67 6d 61 73 6b 00                          logmask.
> >>>>>>>      backtrace:
> >>>>>>>        [<00000000306e441c>] __kmalloc_node_track_caller+0x44/0x1b0
> >>>>>>>        [<000000007c491a9e>] kstrdup+0x3a/0x70
> >>>>>>>        [<0000000015719a3b>] kstrdup_const+0x63/0x80
> >>>>>>>        [<0000000084e458ea>] kvasprintf_const+0x149/0x180
> >>>>>>>        [<0000000091302b42>] kobject_set_name_vargs+0x56/0x150
> >>>>>>>        [<000000005f48eeac>] kobject_set_name+0xab/0xe0
> >>>>>>>
> >>>>>>> Fixes: 34980ca8faeb ("Drivers: clean up direct setting of the name of a kset")
> >>>>>>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
> >>>>>>> ---
> >>>>>>>     fs/ocfs2/cluster/masklog.c | 7 ++++++-
> >>>>>>>     1 file changed, 6 insertions(+), 1 deletion(-)
> >>>>>>>
> >>>>>>> diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
> >>>>>>> index 563881ddbf00..7f9ba816d955 100644
> >>>>>>> --- a/fs/ocfs2/cluster/masklog.c
> >>>>>>> +++ b/fs/ocfs2/cluster/masklog.c
> >>>>>>> @@ -156,6 +156,7 @@ static struct kset mlog_kset = {
> >>>>>>>     int mlog_sys_init(struct kset *o2cb_kset)
> >>>>>>>     {
> >>>>>>>         int i = 0;
> >>>>>>> +    int ret;
> >>>>>>>           while (mlog_attrs[i].attr.mode) {
> >>>>>>>             mlog_default_attrs[i] = &mlog_attrs[i].attr;
> >>>>>>> @@ -165,7 +166,11 @@ int mlog_sys_init(struct kset *o2cb_kset)
> >>>>>>>           kobject_set_name(&mlog_kset.kobj, "logmask");
> >>>>>>>         mlog_kset.kobj.kset = o2cb_kset;
> >>>>>>> -    return kset_register(&mlog_kset);
> >>>>>>> +    ret = kset_register(&mlog_kset);
> >>>>>> If register fails, it will call unregister in o2cb_sys_init(), which
> >>>>>> will put kobject.
> >>>>> They are different ksets, the kset unregistered in o2cb_sys_init() is 'o2cb_kset', the
> >>>>> kset used to registered in mlog_sys_init() is 'mlog_kset', and they hold difference
> >>>>> refcounts.
> >>>>> Yes, you are right. I've mixed the two ksets up.
> >>>> In theory, kset_register() may return error because of a NULL kset, so
> >>>> here we may not call kset_put() directly, I'm not sure if a static
> >>>> checker will happy.
> >>>> Though this can't happen since it's already statically allocated...
> >>> kset_register() may fail if kobject_add_internal() return error (can't allocate memory), the name
> >>> "logmask" is dynamically alloctated while ocfs2 is compile as module and insert it (if ocfs2 is
> >>> built in kernel, the name is constant, it won't cause a leak), so the name can be leaked.
> >> What I mean is kset_register() may fail with many reasons, or even
> >> without kset_init().
> >> I wonder if we have to handle this internal kset_register(), but not
> >> leave it to caller. This may benefit other callers as well.
> >>
> >> Something like:
> >> err = kobject_add_internal(&k->kobj);
> >> if (err) {
> >>     kset_put(k);
> >>     return err;
> >> }
> > I had think about this method to fix this, but some kset is allocated dynamically in driver and
> > it's freed in callback function which is called after kset_put() and in error path in driver will free
> > it again, it leads double free in some drivers.
> > 
> I don't think it's good idea that caller has to take care part of the
> internal logic of kset_register() in case of error.
> Hi Greg, what do you think?

I think if you are messing around with raw ksets, you have to handle
them properly :)

For some driver and kobject core functions, once you call register, you
have to call put() to handle an error because the driver core can not
know what you are doing with that memory at times.

But, maybe for ksets this is not needed and the kobject core can
properly clean up from an error here.  Yang, can you please look into
this?  That might make this much simpler.

Either way, the documentation for kset_register() needs to be fixed up
first, so that people have a chance to know what to do here and THEN we
can fix up the callers like this.

Yang, can you do this all as one long series that I can take through the
driver core tree.  No need to scatter it all across a bunch of different
subsystems.

thanks,

greg k-h

Re: [PATCH] ocfs2: possible memory leak in mlog_sys_init()

[Yang Yingliang]

On 2022/10/20 18:18, Greg Kroah-Hartman wrote:
> On Thu, Oct 20, 2022 at 10:06:48AM +0800, Joseph Qi wrote:
>>
>> On 10/19/22 10:57 AM, Yang Yingliang wrote:
>>> On 2022/10/19 10:26, Joseph Qi wrote:
>>>> On 10/18/22 10:28 PM, Yang Yingliang wrote:
>>>>> On 2022/10/18 21:39, Joseph Qi wrote:
>>>>>> On 10/18/22 6:33 PM, Yang Yingliang wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 2022/10/18 17:02, Joseph Qi wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 10/18/22 3:52 PM, Yang Yingliang wrote:
>>>>>>>>> Inject fault while probing module, kset_register() may fail,
>>>>>>>>> if it fails, but the refcount of kobject is not decreased to
>>>>>>>>> 0, the name allocated in kobject_set_name() is leaked. Fix
>>>>>>>>> this by calling kset_put(), so that name can be freed in
>>>>>>>>> callback function kobject_cleanup().
>>>>>>>>>
>>>>>>>>> unreferenced object 0xffff888100da9348 (size 8):
>>>>>>>>>       comm "modprobe", pid 257, jiffies 4294701096 (age 33.334s)
>>>>>>>>>       hex dump (first 8 bytes):
>>>>>>>>>         6c 6f 67 6d 61 73 6b 00                          logmask.
>>>>>>>>>       backtrace:
>>>>>>>>>         [<00000000306e441c>] __kmalloc_node_track_caller+0x44/0x1b0
>>>>>>>>>         [<000000007c491a9e>] kstrdup+0x3a/0x70
>>>>>>>>>         [<0000000015719a3b>] kstrdup_const+0x63/0x80
>>>>>>>>>         [<0000000084e458ea>] kvasprintf_const+0x149/0x180
>>>>>>>>>         [<0000000091302b42>] kobject_set_name_vargs+0x56/0x150
>>>>>>>>>         [<000000005f48eeac>] kobject_set_name+0xab/0xe0
>>>>>>>>>
>>>>>>>>> Fixes: 34980ca8faeb ("Drivers: clean up direct setting of the name of a kset")
>>>>>>>>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
>>>>>>>>> ---
>>>>>>>>>      fs/ocfs2/cluster/masklog.c | 7 ++++++-
>>>>>>>>>      1 file changed, 6 insertions(+), 1 deletion(-)
>>>>>>>>>
>>>>>>>>> diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c
>>>>>>>>> index 563881ddbf00..7f9ba816d955 100644
>>>>>>>>> --- a/fs/ocfs2/cluster/masklog.c
>>>>>>>>> +++ b/fs/ocfs2/cluster/masklog.c
>>>>>>>>> @@ -156,6 +156,7 @@ static struct kset mlog_kset = {
>>>>>>>>>      int mlog_sys_init(struct kset *o2cb_kset)
>>>>>>>>>      {
>>>>>>>>>          int i = 0;
>>>>>>>>> +    int ret;
>>>>>>>>>            while (mlog_attrs[i].attr.mode) {
>>>>>>>>>              mlog_default_attrs[i] = &mlog_attrs[i].attr;
>>>>>>>>> @@ -165,7 +166,11 @@ int mlog_sys_init(struct kset *o2cb_kset)
>>>>>>>>>            kobject_set_name(&mlog_kset.kobj, "logmask");
>>>>>>>>>          mlog_kset.kobj.kset = o2cb_kset;
>>>>>>>>> -    return kset_register(&mlog_kset);
>>>>>>>>> +    ret = kset_register(&mlog_kset);
>>>>>>>> If register fails, it will call unregister in o2cb_sys_init(), which
>>>>>>>> will put kobject.
>>>>>>> They are different ksets, the kset unregistered in o2cb_sys_init() is 'o2cb_kset', the
>>>>>>> kset used to registered in mlog_sys_init() is 'mlog_kset', and they hold difference
>>>>>>> refcounts.
>>>>>>> Yes, you are right. I've mixed the two ksets up.
>>>>>> In theory, kset_register() may return error because of a NULL kset, so
>>>>>> here we may not call kset_put() directly, I'm not sure if a static
>>>>>> checker will happy.
>>>>>> Though this can't happen since it's already statically allocated...
>>>>> kset_register() may fail if kobject_add_internal() return error (can't allocate memory), the name
>>>>> "logmask" is dynamically alloctated while ocfs2 is compile as module and insert it (if ocfs2 is
>>>>> built in kernel, the name is constant, it won't cause a leak), so the name can be leaked.
>>>> What I mean is kset_register() may fail with many reasons, or even
>>>> without kset_init().
>>>> I wonder if we have to handle this internal kset_register(), but not
>>>> leave it to caller. This may benefit other callers as well.
>>>>
>>>> Something like:
>>>> err = kobject_add_internal(&k->kobj);
>>>> if (err) {
>>>>      kset_put(k);
>>>>      return err;
>>>> }
>>> I had think about this method to fix this, but some kset is allocated dynamically in driver and
>>> it's freed in callback function which is called after kset_put() and in error path in driver will free
>>> it again, it leads double free in some drivers.
>>>
>> I don't think it's good idea that caller has to take care part of the
>> internal logic of kset_register() in case of error.
>> Hi Greg, what do you think?
> I think if you are messing around with raw ksets, you have to handle
> them properly :)
>
> For some driver and kobject core functions, once you call register, you
> have to call put() to handle an error because the driver core can not
> know what you are doing with that memory at times.
>
> But, maybe for ksets this is not needed and the kobject core can
> properly clean up from an error here.  Yang, can you please look into
> this?  That might make this much simpler.
OK, I will look into this to see how to make it simpler for drivers.
>
> Either way, the documentation for kset_register() needs to be fixed up
> first, so that people have a chance to know what to do here and THEN we
> can fix up the callers like this.
>
> Yang, can you do this all as one long series that I can take through the
> driver core tree.  No need to scatter it all across a bunch of different
> subsystems.
OK, I will fix all these in one series.

Thanks,
Yang
>
> thanks,
>
> greg k-h
> .