All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yuehaibing <yuehaibing@huawei.com>
To: Miroslav Benes <mbenes@suse.cz>
Cc: <jeyu@kernel.org>, <gregkh@linuxfoundation.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] kernel/module: Fix mem leak in module_add_modinfo_attrs
Date: Tue, 4 Jun 2019 21:54:44 +0800	[thread overview]
Message-ID: <5705910c-ea13-9ff0-0d94-f2311fa510d9@huawei.com> (raw)
In-Reply-To: <alpine.LSU.2.21.1906041107510.16030@pobox.suse.cz>

On 2019/6/4 18:46, Miroslav Benes wrote:
> On Mon, 3 Jun 2019, YueHaibing wrote:
> 
>> In module_add_modinfo_attrs if sysfs_create_file
>> fails, we forget to free allocated modinfo_attrs
>> and roll back the sysfs files.
>>
>> Fixes: 03e88ae1b13d ("[PATCH] fix module sysfs files reference counting")
>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>> ---
>> v3: reuse module_remove_modinfo_attrs
>> v2: free from '--i' instead of 'i--'
>> ---
>>  kernel/module.c | 21 ++++++++++++++++-----
>>  1 file changed, 16 insertions(+), 5 deletions(-)
> 
> I'm afraid it is not completely correct.
>  
>> diff --git a/kernel/module.c b/kernel/module.c
>> index 80c7c09..c6b8912 100644
>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -1697,6 +1697,8 @@ static int add_usage_links(struct module *mod)
>>  	return ret;
>>  }
>>  
>> +static void module_remove_modinfo_attrs(struct module *mod, int end);
>> +
>>  static int module_add_modinfo_attrs(struct module *mod)
>>  {
>>  	struct module_attribute *attr;
>> @@ -1711,24 +1713,33 @@ static int module_add_modinfo_attrs(struct module *mod)
>>  		return -ENOMEM;
>>  
>>  	temp_attr = mod->modinfo_attrs;
>> -	for (i = 0; (attr = modinfo_attrs[i]) && !error; i++) {
>> +	for (i = 0; (attr = modinfo_attrs[i]); i++) {
>>  		if (!attr->test || attr->test(mod)) {
>>  			memcpy(temp_attr, attr, sizeof(*temp_attr));
>>  			sysfs_attr_init(&temp_attr->attr);
>>  			error = sysfs_create_file(&mod->mkobj.kobj,
>>  					&temp_attr->attr);
>> +			if (error)
>> +				goto error_out;
> 
> sysfs_create_file() failed, so we need to clear all previously processed 
> attrs and not the current one.
> 
>>  			++temp_attr;
>>  		}
>>  	}
>> +
>> +	return 0;
>> +
>> +error_out:
>> +	module_remove_modinfo_attrs(mod, --i);
> 
> It says "call sysfs_remove_file() on all attrs ending with --i included 
> (all correctly processed attrs).
> 
>>  	return error;
>>  }
>>  
>> -static void module_remove_modinfo_attrs(struct module *mod)
>> +static void module_remove_modinfo_attrs(struct module *mod, int end)
>>  {
>>  	struct module_attribute *attr;
>>  	int i;
>>  
>>  	for (i = 0; (attr = &mod->modinfo_attrs[i]); i++) {
>> +		if (end >= 0 && i > end)
>> +			break;
> 
> If end == 0, you break the loop without calling sysfs_remove_file(), which 
> is a bug if you called module_remove_modinfo_attrs(mod, 0).

If end == 0 and i == 0, if statement is false, it won't break the loop.

At other places, I use end == -1, which means clean all and keeps the old behavior

-	module_remove_modinfo_attrs(mod);
+	module_remove_modinfo_attrs(mod, -1);


> 
> Calling module_remove_modinfo_attrs(mod, i); in module_add_modinfo_attrs() 
> under error_out label and changing the condition here to 
> 
> if (end >= 0 && i >= end)
> 	break;
> 
> should work as expected.
> 
> But let me ask another question and it might be more to Jessica. Why is 
> there even a call to attr->free(mod); (if it exists) in 
> module_remove_modinfo_attrs()? The same is in free_modinfo() (as opposed 
> to setup_modinfo() where attr->setup(mod) is called. Is it because 
> free_modinfo() is called only in load_module()'s error path, while 
> module_remove_modinfo_attrs() is called even in free_module() path?
> 
> kfree() checks for NULL pointer, so there is no bug, but it is certainly 
> not nice and it calls for cleanup. But I may be missing something.
> 
> Regards,
> Miroslav
> 
> .
> 


  reply	other threads:[~2019-06-04 13:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-15 16:12 [PATCH] kernel/module: Fix mem leak in module_add_modinfo_attrs YueHaibing
2019-05-30  9:24 ` Yuehaibing
2019-05-30 11:45 ` Jessica Yu
2019-05-30 13:32   ` Yuehaibing
2019-05-30 13:43 ` [PATCH v2] " YueHaibing
2019-06-03 10:47   ` Jessica Yu
2019-06-03 12:41     ` Yuehaibing
2019-06-03 12:11   ` Miroslav Benes
2019-06-03 14:45     ` Yuehaibing
2019-06-03 14:45   ` [PATCH v3] " YueHaibing
2019-06-04 10:46     ` Miroslav Benes
2019-06-04 13:54       ` Yuehaibing [this message]
2019-06-04 14:15         ` Miroslav Benes
2019-06-07 14:02       ` Jessica Yu
2019-06-11 13:33     ` Jessica Yu
2019-06-11 14:30       ` Yuehaibing
2019-06-11 15:38         ` Greg KH
2019-06-11 15:00     ` [PATCH v4] " YueHaibing
2019-06-12 11:12       ` Miroslav Benes
2019-06-14  7:54       ` Jessica Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5705910c-ea13-9ff0-0d94-f2311fa510d9@huawei.com \
    --to=yuehaibing@huawei.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jeyu@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbenes@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.