Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp7853046rwb; Wed, 23 Nov 2022 11:39:00 -0800 (PST) X-Google-Smtp-Source: AA0mqf6ingenzK2xMJcYRorw/tf3549dEfEC7gYZz3O2Sll+5snO7jIc+82tiYFKIxutY6dR6lo3 X-Received: by 2002:a17:90a:4b81:b0:213:5a4d:8138 with SMTP id i1-20020a17090a4b8100b002135a4d8138mr31495968pjh.17.1669232340008; Wed, 23 Nov 2022 11:39:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669232340; cv=none; d=google.com; s=arc-20160816; b=U9R8aZyUAKo5eqAkdqyiGpoDoN1k/T3FE3vTNjt3v9QeTOBx3HyJOaNqua5YYLhNxC TYh2IdYfzFUCvz3J9LMxIYijVKQvDbj26LWn6AFwAfvfoTydNrpAZcjh3dOvUg7pEhlh x8y+SI91gqSI/2WIZkceWPG8zOKd1zBS4pmjqD55mExPofusswjMOBC7235sQlPa8Gwu i3LFv9WsK3KqHhcVLXTqWq32CCAG6mb2v6KPSOyknEOIBEazOTbddJwdSajs/veszopy gyG0MiE/D+OZVdD4xNaHVrrzoBkFUOTRPudhoFxyXQBLZWsAP/YiSCMZ0Y8o7Ok+zxTS otgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=LG4ejPil+Dahi/Uy5Yg/CnimhCPelU4sVJwByLMigfg=; b=mdUypw7EbY94OcVFsoZqBGHJeA5AAZGeEONCU/i+P6OtLAIOMvjyXXAWCCqL+gh9vy RjXwTkBbjl3tf7XWMIPwGyQeciIKkZ44FYDhdOWP7m1QcP5BuGWwYantiHr0WiSNCuQy fL9WRYbDSKUW7QN9fv4VLDsjel69BLeFTCLhqRq+sIGX267GV3ES9E8qWnuuGqmfW1do xHzOfBnVHbYdi+wV8xREIrIjxrgrI3n9JlYxFfzg3j74VtdNtOOGtZF/6gsjh9TOAvxc jVl9gsgMAGsBhiCy+ni/c6P12Q+4UfVpNML/yB5uYkfGDCig10ovQrAGM9201LG8/mC6 MIqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=ZRlIjb9F; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c2-20020a170903234200b001891957c091si12030042plh.501.2022.11.23.11.38.49; Wed, 23 Nov 2022 11:38:59 -0800 (PST) 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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=ZRlIjb9F; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238261AbiKWT0A (ORCPT + 89 others); Wed, 23 Nov 2022 14:26:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54124 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236711AbiKWTZ7 (ORCPT ); Wed, 23 Nov 2022 14:25:59 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A6BB7819C; Wed, 23 Nov 2022 11:25:58 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 30EAFB82449; Wed, 23 Nov 2022 19:25:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B189C433D6; Wed, 23 Nov 2022 19:25:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1669231556; bh=ZeVSW+ifrT0umNWkh6DjnXkC3E2D1rhSRIgT3S+8KK8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZRlIjb9FmwcHaugpvh9e2plbxSjpYyGA+JfHE55vRI7nLXfkTAVkuvR6sx2+pBuOL MFI0dzW5VBTh4Lfi0eq+2QoT+DDtOnXQccP0GkytesG6uiaxZRDtHxZDdLOYaA8w14 I0tiHeGoU9ZBbbQBOnxviCW/od9/AqAQVehxFu0c= Date: Wed, 23 Nov 2022 20:25:53 +0100 From: Greg Kroah-Hartman To: "Rafael J. Wysocki" Cc: Yang Yingliang , linux-pm@vger.kernel.org, Linux Kernel Mailing List Subject: Re: [PATCH] powercap: fix possible name leak while device_register() fails Message-ID: References: <20221112094048.3614365-1-yangyingliang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, 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 Wed, Nov 23, 2022 at 08:00:14PM +0100, Rafael J. Wysocki wrote: > On Sat, Nov 12, 2022 at 10:42 AM Yang Yingliang > wrote: > > > > If device_register() returns error, the name allocated by > > dev_set_name() need be freed. In technical, we should call > > put_device() to give up the reference and free the name in > > driver core, but in some cases the device is not intizalized, > > put_device() can not be called, so don't complicate the code, > > just call kfree_const() to free name in the error path. > > > > Fixes: 75d2364ea0ca ("PowerCap: Add class driver") > > Signed-off-by: Yang Yingliang > > --- > > drivers/powercap/powercap_sys.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/powercap/powercap_sys.c b/drivers/powercap/powercap_sys.c > > index f0654a932b37..11e742dc83b9 100644 > > --- a/drivers/powercap/powercap_sys.c > > +++ b/drivers/powercap/powercap_sys.c > > @@ -572,6 +572,7 @@ struct powercap_zone *powercap_register_zone( > > err_name_alloc: > > idr_remove(power_zone->parent_idr, power_zone->id); > > err_idr_alloc: > > + kfree_const(dev_name(&power_zone->dev)); > > if (power_zone->allocated) > > kfree(power_zone); > > mutex_unlock(&control_type->lock); > > @@ -622,6 +623,7 @@ struct powercap_control_type *powercap_register_control_type( > > dev_set_name(&control_type->dev, "%s", name); > > result = device_register(&control_type->dev); > > if (result) { > > + kfree_const(dev_name(&control_type->dev)); > > Why is it necessary to free a device name explicitly after a failing > device_register()? > > If it is really necessary, then there is a problem in > device_register() itself AFAICS, because it uses dev_set_name() at > least in the dev->init_name present case. I think we already fixed this in the driver core, so these types of patches should not be applied. Yang, can you make sure you respond to all of them and say "this is not needed anymore!" and if any got merged, send reverts for them? thanks, greg k-h