Messages in this thread | | | Date | Tue, 1 Nov 2022 19:57:59 +0800 | Subject | Re: [PATCH] comedi: Fix potential memory leak in comedi_init() | From | shangxiaojing <> |
| |
On 2022/11/1 19: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().
It's ok to add a pair function, but maybe only one place where used cdev_add() need free name. Your mean all "kfree_const(name);" should be replaced to the new function?
> >>> >> 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? > > I'm stuck trying to work out why hfi1_cdev_init() doesn't have the same > problem when cdev_add() returns an error. >
Only user_add() calls the hfi1_cdev_init(), and will call user_remove() if hfi1_cdev_init() failed. In user_remove(), hfi1_cdev_cleanup() will call cdev_del().
Thanks, -- Shang XiaoJing
| |