Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp6080156rwi; Tue, 18 Oct 2022 07:55:00 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4k2hTCT+YVDaxBUevNcvdauUo+fdAbcmMZIfkA2FBnnR7KX5Jx3OS2VZwGGBL1ufIjBZJa X-Received: by 2002:a05:6402:11ce:b0:45c:a2a2:4207 with SMTP id j14-20020a05640211ce00b0045ca2a24207mr2969128edw.3.1666104900141; Tue, 18 Oct 2022 07:55:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666104900; cv=none; d=google.com; s=arc-20160816; b=nM1JwVFpa6hPT3bDRzbVQtlOJgnNG6tLWnur1IGVceQhgCeTiAm6FcgPvgazAmnUVZ +A1C1g9cvyVciOq6GKIgLHpEQIG6DIXnFTTkXqGWTbpZUu1JQziNnUrPH/1qLN15KUL/ SM9I8zvIER7+7P6hf/P7/Dtc+RudLNCaojLOBRFty8Ui+8DU/sVKI6pBbpHZIZFU6zfK 6lBfbRyrh+Uh0xVFq9gVvM/OFfZrD1K0gqCs3y8H1XvXEUW1NOZArksrt+JyFSyzHRfO wZSpV3iA/C+CgsJGabyhZ3NLlcDVdNBo0wAEGhilfDl2rQeAqY2z6IdUrHJr0oykD8s4 2f/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=+GPdy7wwbmNB3sDm7q1ATLj3s9FFYypXnFx8HV29dyM=; b=kFWncKAWZCGSL4gryQKM7r2bx6kR1/huSwnDfvhoa02utrixC8OCUWnBjU82hZEDJp Otq/k8I+j4zCDhzvc7CnZMkWC5Lb7IB+Jqf5JUfugau7NjxCqHc4jE1aY1GW6NBhLh6x T6Z1EsxlJQ9vQhb2RiB+FTnfK96xV/ZFkgBKw5jW4h0RRPl1ekgW8YAboYR6yKRV2W93 5lARJBz6YWjEjEFhxYp3bmQoZC7x3gSUN2lqNyqjsNH66CkcvR+Dexj4PfTPvhG38ipD xIUfSp/VAPbfp7fNXtZ97k8bvGfG1UV/O5SfwS7f9PNDs1EXg9lfjR1i68PU1+MFPNVS iLzA== 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f20-20020a056402355400b0045d5ba4c3cesi9949336edd.47.2022.10.18.07.54.33; Tue, 18 Oct 2022 07:55:00 -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 S231404AbiJRO2j (ORCPT + 99 others); Tue, 18 Oct 2022 10:28:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39750 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229926AbiJRO2h (ORCPT ); Tue, 18 Oct 2022 10:28:37 -0400 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E914BC0981 for ; Tue, 18 Oct 2022 07:28:35 -0700 (PDT) Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.57]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4MsGLv2Qksz1P6vk; Tue, 18 Oct 2022 22:23:51 +0800 (CST) Received: from dggpemm500007.china.huawei.com (7.185.36.183) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 18 Oct 2022 22:28:33 +0800 Received: from [10.174.178.174] (10.174.178.174) 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; Tue, 18 Oct 2022 22:28:33 +0800 Subject: Re: [PATCH] ocfs2: possible memory leak in mlog_sys_init() To: Joseph Qi , , CC: , , , References: <20221018075213.736562-1-yangyingliang@huawei.com> <09bb2844-e20a-98e8-c2af-5b6c4795d48e@huawei.com> From: Yang Yingliang Message-ID: <0db486eb-6927-927e-3629-958f8f211194@huawei.com> Date: Tue, 18 Oct 2022 22:28:32 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [10.174.178.174] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) 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,NICE_REPLY_A, 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: X-Mailing-List: linux-kernel@vger.kernel.org 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 >>>> --- >>>>   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. Thanks, Yang > > Thanks, > Joseph > > .