From: Joseph Qi <joseph.qi@linux.alibaba.com> To: Yang Yingliang <yangyingliang@huawei.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: mark@fasheh.com, jlbec@evilplan.org, akpm@linux-foundation.org, ocfs2-devel <ocfs2-devel@oss.oracle.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [PATCH] ocfs2: possible memory leak in mlog_sys_init() Date: Thu, 20 Oct 2022 10:06:48 +0800 [thread overview] Message-ID: <30747fd7-fe79-2ed8-ce63-425a008e3e4f@linux.alibaba.com> (raw) In-Reply-To: <f6bc6dd3-f7b7-e757-fc36-d1cfbc7305e5@huawei.com> On 10/19/22 10:57 AM, Yang Yingliang wrote: > > On 2022/10/19 10:26, Joseph Qi wrote: >> >> On 10/18/22 10:28 PM, Yang Yingliang wrote: >>> On 2022/10/18 21:39, Joseph Qi wrote: >>>> On 10/18/22 6:33 PM, Yang Yingliang wrote: >>>>> Hi, >>>>> >>>>> On 2022/10/18 17:02, Joseph Qi wrote: >>>>>> Hi, >>>>>> >>>>>> On 10/18/22 3:52 PM, Yang Yingliang wrote: >>>>>>> Inject fault while probing module, kset_register() may fail, >>>>>>> if it fails, but the refcount of kobject is not decreased to >>>>>>> 0, the name allocated in kobject_set_name() is leaked. Fix >>>>>>> this by calling kset_put(), so that name can be freed in >>>>>>> callback function kobject_cleanup(). >>>>>>> >>>>>>> unreferenced object 0xffff888100da9348 (size 8): >>>>>>> comm "modprobe", pid 257, jiffies 4294701096 (age 33.334s) >>>>>>> hex dump (first 8 bytes): >>>>>>> 6c 6f 67 6d 61 73 6b 00 logmask. >>>>>>> backtrace: >>>>>>> [<00000000306e441c>] __kmalloc_node_track_caller+0x44/0x1b0 >>>>>>> [<000000007c491a9e>] kstrdup+0x3a/0x70 >>>>>>> [<0000000015719a3b>] kstrdup_const+0x63/0x80 >>>>>>> [<0000000084e458ea>] kvasprintf_const+0x149/0x180 >>>>>>> [<0000000091302b42>] kobject_set_name_vargs+0x56/0x150 >>>>>>> [<000000005f48eeac>] kobject_set_name+0xab/0xe0 >>>>>>> >>>>>>> Fixes: 34980ca8faeb ("Drivers: clean up direct setting of the name of a kset") >>>>>>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> >>>>>>> --- >>>>>>> fs/ocfs2/cluster/masklog.c | 7 ++++++- >>>>>>> 1 file changed, 6 insertions(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c >>>>>>> index 563881ddbf00..7f9ba816d955 100644 >>>>>>> --- a/fs/ocfs2/cluster/masklog.c >>>>>>> +++ b/fs/ocfs2/cluster/masklog.c >>>>>>> @@ -156,6 +156,7 @@ static struct kset mlog_kset = { >>>>>>> int mlog_sys_init(struct kset *o2cb_kset) >>>>>>> { >>>>>>> int i = 0; >>>>>>> + int ret; >>>>>>> while (mlog_attrs[i].attr.mode) { >>>>>>> mlog_default_attrs[i] = &mlog_attrs[i].attr; >>>>>>> @@ -165,7 +166,11 @@ int mlog_sys_init(struct kset *o2cb_kset) >>>>>>> kobject_set_name(&mlog_kset.kobj, "logmask"); >>>>>>> mlog_kset.kobj.kset = o2cb_kset; >>>>>>> - return kset_register(&mlog_kset); >>>>>>> + ret = kset_register(&mlog_kset); >>>>>> If register fails, it will call unregister in o2cb_sys_init(), which >>>>>> will put kobject. >>>>> They are different ksets, the kset unregistered in o2cb_sys_init() is 'o2cb_kset', the >>>>> kset used to registered in mlog_sys_init() is 'mlog_kset', and they hold difference >>>>> refcounts. >>>>> Yes, you are right. I've mixed the two ksets up. >>>> In theory, kset_register() may return error because of a NULL kset, so >>>> here we may not call kset_put() directly, I'm not sure if a static >>>> checker will happy. >>>> Though this can't happen since it's already statically allocated... >>> kset_register() may fail if kobject_add_internal() return error (can't allocate memory), the name >>> "logmask" is dynamically alloctated while ocfs2 is compile as module and insert it (if ocfs2 is >>> built in kernel, the name is constant, it won't cause a leak), so the name can be leaked. >> What I mean is kset_register() may fail with many reasons, or even >> without kset_init(). >> I wonder if we have to handle this internal kset_register(), but not >> leave it to caller. This may benefit other callers as well. >> >> Something like: >> err = kobject_add_internal(&k->kobj); >> if (err) { >> kset_put(k); >> return err; >> } > I had think about this method to fix this, but some kset is allocated dynamically in driver and > it's freed in callback function which is called after kset_put() and in error path in driver will free > it again, it leads double free in some drivers. > I don't think it's good idea that caller has to take care part of the internal logic of kset_register() in case of error. Hi Greg, what do you think? Thanks, Joseph > I think kset_register() is similar with device_register(), if it fails need another put function to give > up reference in driver. >
WARNING: multiple messages have this Message-ID (diff)
From: Joseph Qi via Ocfs2-devel <ocfs2-devel@oss.oracle.com> To: Yang Yingliang <yangyingliang@huawei.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: ocfs2-devel <ocfs2-devel@oss.oracle.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [Ocfs2-devel] [PATCH] ocfs2: possible memory leak in mlog_sys_init() Date: Thu, 20 Oct 2022 10:06:48 +0800 [thread overview] Message-ID: <30747fd7-fe79-2ed8-ce63-425a008e3e4f@linux.alibaba.com> (raw) In-Reply-To: <f6bc6dd3-f7b7-e757-fc36-d1cfbc7305e5@huawei.com> On 10/19/22 10:57 AM, Yang Yingliang wrote: > > On 2022/10/19 10:26, Joseph Qi wrote: >> >> On 10/18/22 10:28 PM, Yang Yingliang wrote: >>> On 2022/10/18 21:39, Joseph Qi wrote: >>>> On 10/18/22 6:33 PM, Yang Yingliang wrote: >>>>> Hi, >>>>> >>>>> On 2022/10/18 17:02, Joseph Qi wrote: >>>>>> Hi, >>>>>> >>>>>> On 10/18/22 3:52 PM, Yang Yingliang wrote: >>>>>>> Inject fault while probing module, kset_register() may fail, >>>>>>> if it fails, but the refcount of kobject is not decreased to >>>>>>> 0, the name allocated in kobject_set_name() is leaked. Fix >>>>>>> this by calling kset_put(), so that name can be freed in >>>>>>> callback function kobject_cleanup(). >>>>>>> >>>>>>> unreferenced object 0xffff888100da9348 (size 8): >>>>>>> comm "modprobe", pid 257, jiffies 4294701096 (age 33.334s) >>>>>>> hex dump (first 8 bytes): >>>>>>> 6c 6f 67 6d 61 73 6b 00 logmask. >>>>>>> backtrace: >>>>>>> [<00000000306e441c>] __kmalloc_node_track_caller+0x44/0x1b0 >>>>>>> [<000000007c491a9e>] kstrdup+0x3a/0x70 >>>>>>> [<0000000015719a3b>] kstrdup_const+0x63/0x80 >>>>>>> [<0000000084e458ea>] kvasprintf_const+0x149/0x180 >>>>>>> [<0000000091302b42>] kobject_set_name_vargs+0x56/0x150 >>>>>>> [<000000005f48eeac>] kobject_set_name+0xab/0xe0 >>>>>>> >>>>>>> Fixes: 34980ca8faeb ("Drivers: clean up direct setting of the name of a kset") >>>>>>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> >>>>>>> --- >>>>>>> fs/ocfs2/cluster/masklog.c | 7 ++++++- >>>>>>> 1 file changed, 6 insertions(+), 1 deletion(-) >>>>>>> >>>>>>> diff --git a/fs/ocfs2/cluster/masklog.c b/fs/ocfs2/cluster/masklog.c >>>>>>> index 563881ddbf00..7f9ba816d955 100644 >>>>>>> --- a/fs/ocfs2/cluster/masklog.c >>>>>>> +++ b/fs/ocfs2/cluster/masklog.c >>>>>>> @@ -156,6 +156,7 @@ static struct kset mlog_kset = { >>>>>>> int mlog_sys_init(struct kset *o2cb_kset) >>>>>>> { >>>>>>> int i = 0; >>>>>>> + int ret; >>>>>>> while (mlog_attrs[i].attr.mode) { >>>>>>> mlog_default_attrs[i] = &mlog_attrs[i].attr; >>>>>>> @@ -165,7 +166,11 @@ int mlog_sys_init(struct kset *o2cb_kset) >>>>>>> kobject_set_name(&mlog_kset.kobj, "logmask"); >>>>>>> mlog_kset.kobj.kset = o2cb_kset; >>>>>>> - return kset_register(&mlog_kset); >>>>>>> + ret = kset_register(&mlog_kset); >>>>>> If register fails, it will call unregister in o2cb_sys_init(), which >>>>>> will put kobject. >>>>> They are different ksets, the kset unregistered in o2cb_sys_init() is 'o2cb_kset', the >>>>> kset used to registered in mlog_sys_init() is 'mlog_kset', and they hold difference >>>>> refcounts. >>>>> Yes, you are right. I've mixed the two ksets up. >>>> In theory, kset_register() may return error because of a NULL kset, so >>>> here we may not call kset_put() directly, I'm not sure if a static >>>> checker will happy. >>>> Though this can't happen since it's already statically allocated... >>> kset_register() may fail if kobject_add_internal() return error (can't allocate memory), the name >>> "logmask" is dynamically alloctated while ocfs2 is compile as module and insert it (if ocfs2 is >>> built in kernel, the name is constant, it won't cause a leak), so the name can be leaked. >> What I mean is kset_register() may fail with many reasons, or even >> without kset_init(). >> I wonder if we have to handle this internal kset_register(), but not >> leave it to caller. This may benefit other callers as well. >> >> Something like: >> err = kobject_add_internal(&k->kobj); >> if (err) { >> kset_put(k); >> return err; >> } > I had think about this method to fix this, but some kset is allocated dynamically in driver and > it's freed in callback function which is called after kset_put() and in error path in driver will free > it again, it leads double free in some drivers. > I don't think it's good idea that caller has to take care part of the internal logic of kset_register() in case of error. Hi Greg, what do you think? Thanks, Joseph > I think kset_register() is similar with device_register(), if it fails need another put function to give > up reference in driver. > _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
next prev parent reply other threads:[~2022-10-20 2:07 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-10-18 7:52 [PATCH] ocfs2: possible memory leak in mlog_sys_init() Yang Yingliang 2022-10-18 7:52 ` [Ocfs2-devel] " Yang Yingliang via Ocfs2-devel 2022-10-18 9:02 ` Joseph Qi 2022-10-18 9:02 ` [Ocfs2-devel] " Joseph Qi via Ocfs2-devel 2022-10-18 10:33 ` Yang Yingliang 2022-10-18 10:33 ` [Ocfs2-devel] " Yang Yingliang via Ocfs2-devel 2022-10-18 13:39 ` Joseph Qi 2022-10-18 13:39 ` [Ocfs2-devel] " Joseph Qi via Ocfs2-devel 2022-10-18 14:28 ` Yang Yingliang 2022-10-18 14:28 ` [Ocfs2-devel] " Yang Yingliang via Ocfs2-devel 2022-10-19 2:26 ` Joseph Qi 2022-10-19 2:26 ` [Ocfs2-devel] " Joseph Qi via Ocfs2-devel 2022-10-19 2:57 ` Yang Yingliang 2022-10-19 2:57 ` [Ocfs2-devel] " Yang Yingliang via Ocfs2-devel 2022-10-20 2:06 ` Joseph Qi [this message] 2022-10-20 2:06 ` Joseph Qi via Ocfs2-devel 2022-10-20 10:18 ` Greg Kroah-Hartman 2022-10-20 10:18 ` [Ocfs2-devel] " Greg Kroah-Hartman via Ocfs2-devel 2022-10-20 11:57 ` Yang Yingliang 2022-10-20 11:57 ` [Ocfs2-devel] " Yang Yingliang via Ocfs2-devel
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=30747fd7-fe79-2ed8-ce63-425a008e3e4f@linux.alibaba.com \ --to=joseph.qi@linux.alibaba.com \ --cc=akpm@linux-foundation.org \ --cc=gregkh@linuxfoundation.org \ --cc=jlbec@evilplan.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark@fasheh.com \ --cc=ocfs2-devel@oss.oracle.com \ --cc=yangyingliang@huawei.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.