Messages in this thread | | | Date | Wed, 2 Nov 2022 14:06:06 +0800 | Subject | Re: [PATCH] comedi: Fix potential memory leak in comedi_init() | From | shangxiaojing <> |
| |
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
| |