linux-kernel - Re: [PATCH] comedi: Fix potential memory leak in comedi

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]

Date:   Tue, 1 Nov 2022 14:16:25 +0800
From:   shangxiaojing <shangxiaojing@...wei.com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     <abbotti@....co.uk>, <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 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.
> 
Hi,

I had checked all 67 places that used cdev_add(), and only the following 
5 functions set the name before the cdev_add():

1. comedi_init(), will memleak and will be fixed by this patch.
2. hfi1_cdev_init(), won't memleak.
3. qib_cdev_init(), won't memleak.
4. uio_major_init(), won't memleak.
5. __register_chrdev(), won't memleak.

As the result, I just fix the code in comedi_init(). Should I still fix 
the cdev core code, which is free the name in cdev_add() fail path?

Thanks,
-- 
Shang XiaoJing