Message ID | 20221017023327.1793893-1-yangyingliang@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp1236361wrs; Sun, 16 Oct 2022 19:35:20 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5pyKT92pcSLFgt1VLil6W9XEvpcPH88c/i+BL976rcaiqifKlts72qiFz0HqXoL+3rNIxW X-Received: by 2002:a63:8bc3:0:b0:461:c9af:94e0 with SMTP id j186-20020a638bc3000000b00461c9af94e0mr8471780pge.421.1665974120189; Sun, 16 Oct 2022 19:35:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665974120; cv=none; d=google.com; s=arc-20160816; b=JkFoN1SoStjurQCqvOaMYMw1uK9UhUrv2I4xgePkFtuChmJesA3SZ8gEtdqU/8Jc7N YHkrsz2dJCNHkhejWPoLXbrQuGJJQD9EgJGRcvE8hSNvVUtEAMFDJKbopxRnVihBTGo1 MnFvO8goFO9nL7es6t73q4qYtId8IJPRjDsi8b83grdvj6klhXON0S9xhoqDHBRiVqwq iCA+rbOrNexhIwcldc2PJ34HsQjSHv645KpufYccFu42YBl2RfFJ2XKneX+ackfOxGdc e6FHUX+Hpkc6YGn51E/YahySrWlpySQ/YcAOpj8hi1w4v1OQcCNFUz1qCogL94C/1j4X rtxQ== 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=j3z7bGF2zgkHvBFbQ2X8/KppiQ3NqMKl1jiek6pVpsM=; b=VKslwY0unYMgs0K3PezyX5C1AeSGkb3N0MXMCA8zu6H1O7+sy3hU9bKDwwjteeoCdx Q6Vxgan9rPaA0KhYHEYaHHxIKXzvHPPGbD+J5Q6xPLaPLjHcbXjdxkUCGFlZU4FAtB5M LzLesnEqFfWlwbLcUrAZjMqJN/Ssst603eIwaOJUbBZrT4GDj9vU5tgYLdz7a6DA23vj XKgFS5ukE8A/D9KJbuqM51U6jhbS3pKTAf+SgakeKW4zThaYmpdaAkAgX1zEniN1Azdw i0JPDO6vQyg1ffs8Mn31vuBD0rIH7dlePxpGCDR52qDT6nMbnRPcZ37WQoKmI83uUEDx oF5g== 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 f13-20020a056a00228d00b00556c1c66b61si12248253pfe.143.2022.10.16.19.35.04; Sun, 16 Oct 2022 19:35:20 -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 S230434AbiJQCeZ (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Sun, 16 Oct 2022 22:34:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38992 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230423AbiJQCeV (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 16 Oct 2022 22:34:21 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A222BF5 for <linux-kernel@vger.kernel.org>; Sun, 16 Oct 2022 19:34:19 -0700 (PDT) Received: from dggpemm500022.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4MrLfX6v13zHvpG; Mon, 17 Oct 2022 10:34:12 +0800 (CST) Received: from dggpemm500007.china.huawei.com (7.185.36.183) by dggpemm500022.china.huawei.com (7.185.36.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 17 Oct 2022 10:34:05 +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, 17 Oct 2022 10:34:04 +0800 From: Yang Yingliang <yangyingliang@huawei.com> To: <linux-kernel@vger.kernel.org> CC: <gregkh@linuxfoundation.org>, <rafael@kernel.org> Subject: [PATCH] kobject: fix possible memory leak in kset_create_and_add() Date: Mon, 17 Oct 2022 10:33:27 +0800 Message-ID: <20221017023327.1793893-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: dggems705-chm.china.huawei.com (10.3.19.182) 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?1746900479123638497?= X-GMAIL-MSGID: =?utf-8?q?1746900479123638497?= |
Series |
kobject: fix possible memory leak in kset_create_and_add()
|
|
Commit Message
Yang Yingliang
Oct. 17, 2022, 2:33 a.m. UTC
If kset_register() fails in kset_create_and_add(), the name allocated
in kset_create() will be leaked. To fix this by calling kset_put() so
that the name will be freed in callback function kobject_cleanup() and
kset will be freed in kset_release().
unreferenced object 0xffff888103cc8c08 (size 8):
comm "modprobe", pid 508, jiffies 4294915182 (age 120.020s)
hex dump (first 8 bytes):
62 79 5f 6e 61 6d 65 00 by_name.
backtrace:
[<00000000572f97f9>] __kmalloc_track_caller+0x1ae/0x320
[<00000000a167a5cc>] kstrdup+0x3a/0x70
[<000000001cd0d05e>] kstrdup_const+0x68/0x80
[<00000000b9101e6d>] kvasprintf_const+0x10b/0x190
[<0000000088f2b8df>] kobject_set_name_vargs+0x56/0x150
[<000000003f8aca68>] kobject_set_name+0xab/0xe0
[<00000000249f7816>] kset_create_and_add+0x72/0x200
Fixes: b727c702896f ("kset: add kset_create_and_add function")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
---
lib/kobject.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Mon, Oct 17, 2022 at 10:33:27AM +0800, Yang Yingliang wrote: > If kset_register() fails in kset_create_and_add(), the name allocated > in kset_create() will be leaked. How is kset_create_and_add() failing? Is this in a real kernel, or created with a fake fault injection? thanks, greg k-h
Hi, On 2022/10/17 12:51, Greg KH wrote: > On Mon, Oct 17, 2022 at 10:33:27AM +0800, Yang Yingliang wrote: >> If kset_register() fails in kset_create_and_add(), the name allocated >> in kset_create() will be leaked. > How is kset_create_and_add() failing? Is this in a real kernel, or > created with a fake fault injection? Inject fault while probing module qemu_fw_cfg, kset_create_and_add() may fail. Thanks, Yang > > thanks, > > greg k-h > .
On Mon, Oct 17, 2022 at 04:13:03PM +0800, Yang Yingliang wrote: > Hi, > > On 2022/10/17 12:51, Greg KH wrote: > > On Mon, Oct 17, 2022 at 10:33:27AM +0800, Yang Yingliang wrote: > > > If kset_register() fails in kset_create_and_add(), the name allocated > > > in kset_create() will be leaked. > > How is kset_create_and_add() failing? Is this in a real kernel, or > > created with a fake fault injection? > Inject fault while probing module qemu_fw_cfg, kset_create_and_add() may > fail. Ah good, it's never being hit in a real situation. The next time you submit patches that are found like this, please include this type of information. thanks, greg k-h
On 2022/10/17 16:49, Greg KH wrote: > On Mon, Oct 17, 2022 at 04:13:03PM +0800, Yang Yingliang wrote: >> Hi, >> >> On 2022/10/17 12:51, Greg KH wrote: >>> On Mon, Oct 17, 2022 at 10:33:27AM +0800, Yang Yingliang wrote: >>>> If kset_register() fails in kset_create_and_add(), the name allocated >>>> in kset_create() will be leaked. >>> How is kset_create_and_add() failing? Is this in a real kernel, or >>> created with a fake fault injection? >> Inject fault while probing module qemu_fw_cfg, kset_create_and_add() may >> fail. > Ah good, it's never being hit in a real situation. The next time you > submit patches that are found like this, please include this type of > information. OK. Do I need to send a v2 with commit message update. Thanks, Yang > > thanks, > > greg k-h > .
On Mon, Oct 17, 2022 at 05:01:04PM +0800, Yang Yingliang wrote: > > On 2022/10/17 16:49, Greg KH wrote: > > On Mon, Oct 17, 2022 at 04:13:03PM +0800, Yang Yingliang wrote: > > > Hi, > > > > > > On 2022/10/17 12:51, Greg KH wrote: > > > > On Mon, Oct 17, 2022 at 10:33:27AM +0800, Yang Yingliang wrote: > > > > > If kset_register() fails in kset_create_and_add(), the name allocated > > > > > in kset_create() will be leaked. > > > > How is kset_create_and_add() failing? Is this in a real kernel, or > > > > created with a fake fault injection? > > > Inject fault while probing module qemu_fw_cfg, kset_create_and_add() may > > > fail. > > Ah good, it's never being hit in a real situation. The next time you > > submit patches that are found like this, please include this type of > > information. > OK. Do I need to send a v2 with commit message update. That would be wonderful for you to do, thank you! Also do the same thing for the other patches you sent that fix up error paths like this. thanks, greg k-h
diff --git a/lib/kobject.c b/lib/kobject.c index a0b2dbfcfa23..f5e943c9027b 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -982,7 +982,7 @@ struct kset *kset_create_and_add(const char *name, return NULL; error = kset_register(kset); if (error) { - kfree(kset); + kset_put(kset); return NULL; } return kset;