From: shangxiaojing <shangxiaojing@huawei.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Ian Abbott <abbotti@mev.co.uk>, <hsweeten@visionengravers.com>,
<zhangxuezhi1@coolpad.com>, <fmhess@users.sourceforge.net>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] comedi: Fix potential memory leak in comedi_init()
Date: Wed, 2 Nov 2022 14:06:06 +0800 [thread overview]
Message-ID: <dfcd3ebe-6dbc-ccf0-32dc-4934e862aabc@huawei.com> (raw)
In-Reply-To: <Y2HdC8N+DroZ8BKu@kroah.com>
On 2022/11/2 10:59, Greg KH wrote:
> On Wed, Nov 02, 2022 at 10:51:35AM +0800, shangxiaojing wrote:
>>
>>
>> On 2022/11/2 0:41, Ian Abbott wrote:
>>> On 01/11/2022 11:40, Ian Abbott wrote:
>>>> On 01/11/2022 06:16, shangxiaojing wrote:
>>>>>
>>>>>
>>>>> On 2022/11/1 12:45, Greg KH wrote:
>>>>>> On Tue, Nov 01, 2022 at 11:21:25AM +0800, Shang XiaoJing wrote:
>>>>>>> comedi_init() will goto out_unregister_chrdev_region if cdev_add()
>>>>>>> failed, which won't free the resource alloced in kobject_set_name().
>>>>>>> Call kfree_const() to free the leaked name before goto
>>>>>>> out_unregister_chrdev_region.
>>>>>>>
>>>>>>> unreferenced object 0xffff8881000fa8c0 (size 8):
>>>>>>> comm "modprobe", pid 239, jiffies 4294905173 (age 51.308s)
>>>>>>> hex dump (first 8 bytes):
>>>>>>> 63 6f 6d 65 64 69 00 ff comedi..
>>>>>>> backtrace:
>>>>>>> [<000000005f9878f7>] __kmalloc_node_track_caller+0x4c/0x1c0
>>>>>>> [<000000000fd70302>] kstrdup+0x3f/0x70
>>>>>>> [<000000009428bc33>] kstrdup_const+0x46/0x60
>>>>>>> [<00000000ed50d9de>] kvasprintf_const+0xdb/0xf0
>>>>>>> [<00000000b2766964>] kobject_set_name_vargs+0x3c/0xe0
>>>>>>> [<00000000f2424ef7>] kobject_set_name+0x62/0x90
>>>>>>> [<000000005d5a125b>] 0xffffffffa0013098
>>>>>>> [<00000000f331e663>] do_one_initcall+0x7a/0x380
>>>>>>> [<00000000aa7bac96>] do_init_module+0x5c/0x230
>>>>>>> [<000000005fd72335>] load_module+0x227d/0x2420
>>>>>>> [<00000000ad550cf1>] __do_sys_finit_module+0xd5/0x140
>>>>>>> [<00000000069a60c5>] do_syscall_64+0x3f/0x90
>>>>>>> [<00000000c5e0d521>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
>>>>>>>
>>>>>>> Fixes: ed9eccbe8970 ("Staging: add comedi core")
>>>>>>> Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
>>>>>>> ---
>>>>>>> drivers/comedi/comedi_fops.c | 5 ++++-
>>>>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/drivers/comedi/comedi_fops.c
>>>>>>> b/drivers/comedi/comedi_fops.c
>>>>>>> index e2114bcf815a..2c508c2cf6f6 100644
>>>>>>> --- a/drivers/comedi/comedi_fops.c
>>>>>>> +++ b/drivers/comedi/comedi_fops.c
>>>>>>> @@ -3379,8 +3379,11 @@ static int __init comedi_init(void)
>>>>>>> retval = cdev_add(&comedi_cdev, MKDEV(COMEDI_MAJOR, 0),
>>>>>>> COMEDI_NUM_MINORS);
>>>>>>> - if (retval)
>>>>>>> + if (retval) {
>>>>>>> + kfree_const(comedi_cdev.kobj.name);
>>>>>>> + comedi_cdev.kobj.name = NULL;
>>>>>>> goto out_unregister_chrdev_region;
>>>>>>> + }
>>>>>>
>>>>>> A driver should never have to poke around in the internals of a cdev
>>>>>> object like this. Please fix the cdev core to not need this if
>>>>>> cdev_add() fails.
>>>>
>>>> Or at least there should be a function that can be called to undo
>>>> the allocations of kobject_set_name().
>>>
>>> Looking at it a bit more, cdev_init() calls kobject_init(), and
>>> kobject_init() requires a matching call to kobject_put(). Nothing is
>>> calling kobject_put() in this situation. Calling cdev_del() will call
>>> kobject_put(), so is that the correct way to clean up after cdev_init()
>>> if the call to cdev_add() fails?
>>>
>>
>> Some cdev call cdev_del() when cdev_add() failed (like init_dvbdev()), and
>> at that time the cdev_unmap() in cdev_del() won't do anything due to the
>> failure of cdev_add(), which is calling the kobject_put() when cdev_add()
>> failed. But I'm not sure which one is better.
>
> My point is that no one calling the cdev_add() call should have to do
> this type of "cleanup" The cdev code should do it automatically, we
> don't want to have to audit every user of cdev_add() today, and in the
> future for forever, to ensure they got it right.
>
> Let's fix it up in the cdev code itself please. The kobject in a cdev
> is a very odd thing, it's not the "normal" type of kobject that you
> expect, so the cdev code should handle all of that on its own and that
> should not "leak" into any caller.
>
ok, I'll fix in cdev code and send v2.
Thanks,
--
Shang XiaoJing
prev parent reply other threads:[~2022-11-02 6:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-01 3:21 [PATCH] comedi: Fix potential memory leak in comedi_init() Shang XiaoJing
2022-11-01 4:45 ` Greg KH
2022-11-01 6:16 ` shangxiaojing
2022-11-01 11:40 ` Ian Abbott
2022-11-01 11:57 ` shangxiaojing
2022-11-01 15:59 ` Ian Abbott
2022-11-02 2:41 ` shangxiaojing
2022-11-01 16:41 ` Ian Abbott
2022-11-02 2:51 ` shangxiaojing
2022-11-02 2:59 ` Greg KH
2022-11-02 6:06 ` shangxiaojing [this message]
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=dfcd3ebe-6dbc-ccf0-32dc-4934e862aabc@huawei.com \
--to=shangxiaojing@huawei.com \
--cc=abbotti@mev.co.uk \
--cc=fmhess@users.sourceforge.net \
--cc=gregkh@linuxfoundation.org \
--cc=hsweeten@visionengravers.com \
--cc=linux-kernel@vger.kernel.org \
--cc=zhangxuezhi1@coolpad.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).