Message ID | 20221024121910.1169801-1-yangyingliang@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp581010wru; Mon, 24 Oct 2022 10:59:37 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5uZ6zScqZSxvz2SOMwFMIXznoMdHTqdbQYcL5JE6WBrcLggGqRA57G8x7XccBUzstf+5Hd X-Received: by 2002:a17:90b:3b4c:b0:213:f05:6a8 with SMTP id ot12-20020a17090b3b4c00b002130f0506a8mr7266797pjb.108.1666634376853; Mon, 24 Oct 2022 10:59:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666634376; cv=none; d=google.com; s=arc-20160816; b=YUR/n7yryErTxDxqpEfRp2uoV6ccyMnkNG75y8t8Rgdksgl9elN85EarL6kRYWWUsy 5NGUJQLsoU6kqddGsdevVbjW6uUzGhhTF1S19iHJ6K8UuFPNeeG2EeWFqK6f3BnWpLIF TJfl/Kf1U0UkDZ4UUQbRTzcvD3aNz1hX6E4gF5lDmbq2ORHIMuwWJGGwS6XJrBVQ1YDb k7yg9ikq8IbLzLM2G6X8yGLC7oppQD0cUAmsrdPmoguGlX/rIGp0L6dFQEwTsHBOB0op hE7A8oqWSojM8wfKSgoA5PBlzvUHxCTyPciegLdNVNQY1TMPsjlmt/s6s7Eq92AknLbN o7nQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=h7exAZDWjbRIFFeWx1JcKusldiDakMz3AN/pwrODSNE=; b=V5IiFGhfuxnL5YIg2LAk7Slzbe7PTfcDEkk1rQoDt0PvxCs5bvRCdSrlP8XOFPwDrV TvNB5h4bo252SJwogqPLxI4AmbQ5zZa2rmbkEHOJDcHxSewEOPcTnr5sbn8/kqz9XFdY rswykx+ImH6GCAxGsOO+KKaHPXS6uS5ZlZozP35Paw7iJzz2+/ylRDma2iHmW2CcDlVu WckT22Qx5lYNxZSLQ4Bz9iBq0n1zKhs880a+UZufZqxv9AfzwuoftzlQaPjniFduv8ZK DJuqI8twUa7qe8hNXQW7DFdjb/6rcIWYKdz9BEH0DJbmDnUMvu9qeiPqGpwYSj/3Utlp je1w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y15-20020a17090322cf00b0017f74f27a53si227840plg.91.2022.10.24.10.59.23; Mon, 24 Oct 2022 10:59:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229819AbiJXRrU (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Mon, 24 Oct 2022 13:47:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231881AbiJXRq6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 24 Oct 2022 13:46:58 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2BB152D1E2 for <linux-kernel@vger.kernel.org>; Mon, 24 Oct 2022 09:22:47 -0700 (PDT) Received: from dggpemm500023.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4MwvD90QZGzVhmf; Mon, 24 Oct 2022 20:15:37 +0800 (CST) Received: from dggpemm500007.china.huawei.com (7.185.36.183) by dggpemm500023.china.huawei.com (7.185.36.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 24 Oct 2022 20:20:21 +0800 Received: from huawei.com (10.175.103.91) by dggpemm500007.china.huawei.com (7.185.36.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 24 Oct 2022 20:20:20 +0800 From: Yang Yingliang <yangyingliang@huawei.com> To: <linux-kernel@vger.kernel.org>, <qemu-devel@nongnu.org>, <linux-f2fs-devel@lists.sourceforge.net>, <linux-erofs@lists.ozlabs.org>, <ocfs2-devel@oss.oracle.com>, <linux-mtd@lists.infradead.org>, <amd-gfx@lists.freedesktop.org> CC: <gregkh@linuxfoundation.org>, <rafael@kernel.org>, <somlo@cmu.edu>, <mst@redhat.com>, <jaegeuk@kernel.org>, <chao@kernel.org>, <hsiangkao@linux.alibaba.com>, <huangjianan@oppo.com>, <mark@fasheh.com>, <jlbec@evilplan.org>, <joseph.qi@linux.alibaba.com>, <akpm@linux-foundation.org>, <alexander.deucher@amd.com>, <luben.tuikov@amd.com>, <richard@nod.at>, <liushixin2@huawei.com> Subject: [PATCH v2] kset: fix memory leak when kset_register() returns error Date: Mon, 24 Oct 2022 20:19:10 +0800 Message-ID: <20221024121910.1169801-1-yangyingliang@huawei.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.103.91] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm500007.china.huawei.com (7.185.36.183) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747586307563451193?= X-GMAIL-MSGID: =?utf-8?q?1747592808249248466?= |
Series |
[v2] kset: fix memory leak when kset_register() returns error
|
|
Commit Message
Yang Yingliang
Oct. 24, 2022, 12:19 p.m. UTC
Inject fault while loading module, kset_register() may fail.
If it fails, the name allocated by kobject_set_name() which
is called before kset_register() is leaked, because refcount
of kobject is hold in kset_init().
As a kset may be embedded in a larger structure which needs
be freed in release() function or error path in callers, we
can not call kset_put() in kset_register(), or it will cause
double free, so just call kfree_const() to free the name and
set it to NULL.
With this fix, the callers don't need to care about the name
freeing and call an extra kset_put() if kset_register() fails.
Suggested-by: Luben Tuikov <luben.tuikov@amd.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
---
v1 -> v2:
Free name inside of kset_register() instead of calling kset_put()
in drivers.
---
lib/kobject.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
Comments
On 2022/10/24 21:52, Greg KH wrote: > On Mon, Oct 24, 2022 at 08:19:10PM +0800, Yang Yingliang wrote: >> Inject fault while loading module, kset_register() may fail. >> If it fails, the name allocated by kobject_set_name() which >> is called before kset_register() is leaked, because refcount >> of kobject is hold in kset_init(). >> >> As a kset may be embedded in a larger structure which needs >> be freed in release() function or error path in callers, we >> can not call kset_put() in kset_register(), or it will cause >> double free, so just call kfree_const() to free the name and >> set it to NULL. >> >> With this fix, the callers don't need to care about the name >> freeing and call an extra kset_put() if kset_register() fails. >> >> Suggested-by: Luben Tuikov <luben.tuikov@amd.com> >> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> >> --- >> v1 -> v2: >> Free name inside of kset_register() instead of calling kset_put() >> in drivers. >> --- >> lib/kobject.c | 8 +++++++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/lib/kobject.c b/lib/kobject.c >> index a0b2dbfcfa23..3409a89c81e5 100644 >> --- a/lib/kobject.c >> +++ b/lib/kobject.c >> @@ -834,6 +834,9 @@ EXPORT_SYMBOL_GPL(kobj_sysfs_ops); >> /** >> * kset_register() - Initialize and add a kset. >> * @k: kset. >> + * >> + * NOTE: On error, the kset.kobj.name allocated by() kobj_set_name() >> + * which is called before kset_register() in caller need be freed. > This comment doesn't make any sense anymore. No caller needs to worry > about this, right? With this fix, the name is freed inside of kset_register(), it can not be accessed, if it allocated dynamically, but callers don't know this if no comment here, they may use it in error path (something like to print error message with it), so how about comment like this to tell callers not to use the name: NOTE: On error, the kset.kobj.name allocated by() kobj_set_name() is freed, it can not be used any more. > >> */ >> int kset_register(struct kset *k) >> { >> @@ -844,8 +847,11 @@ int kset_register(struct kset *k) >> >> kset_init(k); >> err = kobject_add_internal(&k->kobj); >> - if (err) >> + if (err) { >> + kfree_const(k->kobj.name); >> + k->kobj.name = NULL; > Why are you setting the name here to NULL? I set it to NULL to avoid accessing bad pointer in callers, if callers use it in error path, current callers won't use this name pointer in error path, so we can remove this assignment? Thanks, Yang > > thanks, > > greg k-h > .
On 2022-10-24 08:19, Yang Yingliang wrote: > Inject fault while loading module, kset_register() may fail. > If it fails, the name allocated by kobject_set_name() which > is called before kset_register() is leaked, because refcount > of kobject is hold in kset_init(). "is hold" --> "was set". Also, I'd say "which must be called" instead of "is", since we cannot register kobj/kset without a name--the kobj code crashes, and we want to make this clear. IOW, a novice user may wonder where "is" it called, as opposed to learning that they "must" call it to allocate/set a name, before calling kset_register(). So, I'd say this: "If it fails, the name allocated by kobject_set_name() which must be called before a call to kset_regsiter() is leaked, since refcount of kobj was set in kset_init()." > > As a kset may be embedded in a larger structure which needs > be freed in release() function or error path in callers, we Drop "As", start with "A kset". "which needs _to_ be". Also please specify that the release is part of the ktype, like this: "A kset may be embedded in a larger structure which needs to be freed in ktype.release() or error path in callers, we ..." > can not call kset_put() in kset_register(), or it will cause > double free, so just call kfree_const() to free the name and > set it to NULL. > > With this fix, the callers don't need to care about the name > freeing and call an extra kset_put() if kset_register() fails. This is unclear because you're *missing* a verb: "and call an extra kset_put()". Please add the proper verb _between_ "and call", something like, "With this fix, the callers don't need to care about freeing the name of the kset, and _can_ call kset_put() if kset_register() fails." Choose a proper verb here: can, should, cannot, should not, etc. We can do this because you set "kset.kobj.name to NULL, and this is checked for in kobject_cleanup(). We just need to stipulate whether they should/shouldn't have to call kset_put(), or can free the kset and/or the embedding object themselves. This really depends on how we want kset_register() to behave in the future, and on user's own ktype.release implementation... > > Suggested-by: Luben Tuikov <luben.tuikov@amd.com> > Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> > --- > v1 -> v2: > Free name inside of kset_register() instead of calling kset_put() > in drivers. > --- > lib/kobject.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/lib/kobject.c b/lib/kobject.c > index a0b2dbfcfa23..3409a89c81e5 100644 > --- a/lib/kobject.c > +++ b/lib/kobject.c > @@ -834,6 +834,9 @@ EXPORT_SYMBOL_GPL(kobj_sysfs_ops); > /** > * kset_register() - Initialize and add a kset. > * @k: kset. > + * > + * NOTE: On error, the kset.kobj.name allocated by() kobj_set_name() > + * which is called before kset_register() in caller need be freed. > */ > int kset_register(struct kset *k) > { > @@ -844,8 +847,11 @@ int kset_register(struct kset *k) > > kset_init(k); > err = kobject_add_internal(&k->kobj); > - if (err) > + if (err) { > + kfree_const(k->kobj.name); > + k->kobj.name = NULL; > return err; > + } This looks good. It's good you set kset.kobj.name to NULL, so that recovery/free paths don't get confused. Waiting for v3. (I guess this is no different than what we currently do in kobject_cleanup(), so I see it as safe, no-surprises implementation.) Regards, Luben
On 2022-10-24 17:06, Luben Tuikov wrote: > On 2022-10-24 08:19, Yang Yingliang wrote: >> Inject fault while loading module, kset_register() may fail. >> If it fails, the name allocated by kobject_set_name() which >> is called before kset_register() is leaked, because refcount >> of kobject is hold in kset_init(). > > "is hold" --> "was set". > > Also, I'd say "which must be called" instead of "is", since > we cannot register kobj/kset without a name--the kobj code crashes, > and we want to make this clear. IOW, a novice user may wonder > where "is" it called, as opposed to learning that they "must" > call it to allocate/set a name, before calling kset_register(). > > So, I'd say this: > > "If it fails, the name allocated by kobject_set_name() which must > be called before a call to kset_regsiter() is leaked, since > refcount of kobj was set in kset_init()." Actually, to be a bit more clear: "If kset_register() fails, the name allocated by kobject_set_name(), namely kset.kobj.name, which must be called before a call to kset_register(), may be leaked, if the caller doesn't explicitly free it, say by calling kset_put(). To mitigate this, we free the name in kset_register() when an error is encountered, i.e. when kset_register() returns an error." > >> >> As a kset may be embedded in a larger structure which needs >> be freed in release() function or error path in callers, we > > Drop "As", start with "A kset". "which needs _to_ be". > Also please specify that the release is part of the ktype, > like this: > > "A kset may be embedded in a larger structure which needs to be > freed in ktype.release() or error path in callers, we ..." > >> can not call kset_put() in kset_register(), or it will cause >> double free, so just call kfree_const() to free the name and >> set it to NULL. >> >> With this fix, the callers don't need to care about the name >> freeing and call an extra kset_put() if kset_register() fails. > > This is unclear because you're *missing* a verb: > "and call an extra kset_put()". > Please add the proper verb _between_ "and call", something like, > > "With this fix, the callers don't need to care about freeing > the name of the kset, and _can_ call kset_put() if kset_register() fails." > > Choose a proper verb here: can, should, cannot, should not, etc. > > We can do this because you set "kset.kobj.name to NULL, and this > is checked for in kobject_cleanup(). We just need to stipulate > whether they should/shouldn't have to call kset_put(), or can free the kset > and/or the embedding object themselves. This really depends > on how we want kset_register() to behave in the future, and on > user's own ktype.release implementation... Forgot "may", "may not". So, do we want to say "may call kset_put()", like: "With this fix, the callers need not care about freeing the name of the kset, and _may_ call kset_put() if kset_register() fails." Or do we want to say "should" or even "must"--it really depends on what else is (would be) going on in kobj registration. Although, the user may have additional work to be done in the ktype.release() callback for the embedding object. It would be good to give them the freedom, i.e. "may", to call kset_put(). If that's not the case, this must be explicitly stipulated with the proper verb. Regards, Luben
Hi, On 2022/10/25 5:25, Luben Tuikov wrote: > On 2022-10-24 17:06, Luben Tuikov wrote: >> On 2022-10-24 08:19, Yang Yingliang wrote: >>> Inject fault while loading module, kset_register() may fail. >>> If it fails, the name allocated by kobject_set_name() which >>> is called before kset_register() is leaked, because refcount >>> of kobject is hold in kset_init(). >> "is hold" --> "was set". >> >> Also, I'd say "which must be called" instead of "is", since >> we cannot register kobj/kset without a name--the kobj code crashes, >> and we want to make this clear. IOW, a novice user may wonder >> where "is" it called, as opposed to learning that they "must" >> call it to allocate/set a name, before calling kset_register(). >> >> So, I'd say this: >> >> "If it fails, the name allocated by kobject_set_name() which must >> be called before a call to kset_regsiter() is leaked, since >> refcount of kobj was set in kset_init()." > Actually, to be a bit more clear: > > "If kset_register() fails, the name allocated by kobject_set_name(), > namely kset.kobj.name, which must be called before a call to kset_register(), > may be leaked, if the caller doesn't explicitly free it, say by calling kset_put(). > > To mitigate this, we free the name in kset_register() when an error is encountered, > i.e. when kset_register() returns an error." Thanks for you suggestion. > >>> As a kset may be embedded in a larger structure which needs >>> be freed in release() function or error path in callers, we >> Drop "As", start with "A kset". "which needs _to_ be". >> Also please specify that the release is part of the ktype, >> like this: >> >> "A kset may be embedded in a larger structure which needs to be >> freed in ktype.release() or error path in callers, we ..." >> >>> can not call kset_put() in kset_register(), or it will cause >>> double free, so just call kfree_const() to free the name and >>> set it to NULL. >>> >>> With this fix, the callers don't need to care about the name >>> freeing and call an extra kset_put() if kset_register() fails. >> This is unclear because you're *missing* a verb: >> "and call an extra kset_put()". >> Please add the proper verb _between_ "and call", something like, >> >> "With this fix, the callers don't need to care about freeing >> the name of the kset, and _can_ call kset_put() if kset_register() fails." I was mean the callers don't need to care about freeing the name of the kset and the callers don't need to care about calling kset_put() Thanks, Yang >> >> Choose a proper verb here: can, should, cannot, should not, etc. >> >> We can do this because you set "kset.kobj.name to NULL, and this >> is checked for in kobject_cleanup(). We just need to stipulate >> whether they should/shouldn't have to call kset_put(), or can free the kset >> and/or the embedding object themselves. This really depends >> on how we want kset_register() to behave in the future, and on >> user's own ktype.release implementation... > Forgot "may", "may not". > > So, do we want to say "may call kset_put()", like: > > "With this fix, the callers need not care about freeing > the name of the kset, and _may_ call kset_put() if kset_register() fails." > > Or do we want to say "should" or even "must"--it really depends on > what else is (would be) going on in kobj registration. > > Although, the user may have additional work to be done in the ktype.release() > callback for the embedding object. It would be good to give them the freedom, > i.e. "may", to call kset_put(). If that's not the case, this must be explicitly > stipulated with the proper verb. > > Regards, > Luben > > .
On 2022-10-24 08:19, Yang Yingliang wrote: > Inject fault while loading module, kset_register() may fail. > If it fails, the name allocated by kobject_set_name() which > is called before kset_register() is leaked, because refcount > of kobject is hold in kset_init(). > > As a kset may be embedded in a larger structure which needs > be freed in release() function or error path in callers, we > can not call kset_put() in kset_register(), or it will cause > double free, so just call kfree_const() to free the name and > set it to NULL. > > With this fix, the callers don't need to care about the name > freeing and call an extra kset_put() if kset_register() fails. > > Suggested-by: Luben Tuikov <luben.tuikov@amd.com> > Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> > --- > v1 -> v2: > Free name inside of kset_register() instead of calling kset_put() > in drivers. > --- > lib/kobject.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/lib/kobject.c b/lib/kobject.c > index a0b2dbfcfa23..3409a89c81e5 100644 > --- a/lib/kobject.c > +++ b/lib/kobject.c > @@ -834,6 +834,9 @@ EXPORT_SYMBOL_GPL(kobj_sysfs_ops); > /** > * kset_register() - Initialize and add a kset. > * @k: kset. > + * > + * NOTE: On error, the kset.kobj.name allocated by() kobj_set_name() > + * which is called before kset_register() in caller need be freed. > */ The "need be freed" is confusing here because it is not clear if the user needs to do this or if it is done by the code. Since it is the latter, it should read "_is_ freed". Like this (no "NOTE"): "On error, the kset.kobj.name allocated by kobj_set_name(), which must be called before kset_register() is called, is freed by this function." Regards, Luben > int kset_register(struct kset *k) > { > @@ -844,8 +847,11 @@ int kset_register(struct kset *k) > > kset_init(k); > err = kobject_add_internal(&k->kobj); > - if (err) > + if (err) { > + kfree_const(k->kobj.name); > + k->kobj.name = NULL; > return err; > + } > kobject_uevent(&k->kobj, KOBJ_ADD); > return 0; > }
diff --git a/lib/kobject.c b/lib/kobject.c index a0b2dbfcfa23..3409a89c81e5 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -834,6 +834,9 @@ EXPORT_SYMBOL_GPL(kobj_sysfs_ops); /** * kset_register() - Initialize and add a kset. * @k: kset. + * + * NOTE: On error, the kset.kobj.name allocated by() kobj_set_name() + * which is called before kset_register() in caller need be freed. */ int kset_register(struct kset *k) { @@ -844,8 +847,11 @@ int kset_register(struct kset *k) kset_init(k); err = kobject_add_internal(&k->kobj); - if (err) + if (err) { + kfree_const(k->kobj.name); + k->kobj.name = NULL; return err; + } kobject_uevent(&k->kobj, KOBJ_ADD); return 0; }