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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <04bf1874-77bc-ce73-28e2-04fe4d098e58@mev.co.uk>
Date:   Tue, 1 Nov 2022 16:41:30 +0000
From:   Ian Abbott <abbotti@....co.uk>
To:     shangxiaojing <shangxiaojing@...wei.com>,
        Greg KH <gregkh@...uxfoundation.org>
Cc:     hsweeten@...ionengravers.com, zhangxuezhi1@...lpad.com,
        fmhess@...rs.sourceforge.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] comedi: Fix potential memory leak in comedi_init()

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@...wei.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?

-- 
-=( Ian Abbott <abbotti@....co.uk> || MEV Ltd. is a company  )=-
-=( registered in England & Wales.  Regd. number: 02862268.  )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ