Message ID | 20230403182808.8699-1-n.zhandarovich@fintech.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2507371vqo; Mon, 3 Apr 2023 11:41:50 -0700 (PDT) X-Google-Smtp-Source: AKy350bqCYYgxW1dh0H3ydrtyBxfyGj98GlMPDrEqZZ0FZu1oM5I41q/39AytLbOYaRa5y6lPsXT X-Received: by 2002:a17:906:a015:b0:8af:3382:e578 with SMTP id p21-20020a170906a01500b008af3382e578mr18677113ejy.4.1680547310642; Mon, 03 Apr 2023 11:41:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680547310; cv=none; d=google.com; s=arc-20160816; b=m5HjR9OFWO3rBAw0ryDXiVaRIkFLHOfcwFx7EOhOvZZ/ZlwnSGDJa5pJjqhzOXz56R j5GJyjBdyApHtkBIRvcMWurXG5ujbAo9AO/4lZ4vqcQU1B51U5z+rYdyq96o+3tjm7U+ shq8xOHDxRz3tFuLora65GL6jvXAyhd1lT2c4vBkkHqfjBbr0qhNy2KboKeWgXpPVvCI 8K0815eDflB9pqzMmYGbCszZ+N3gMEqRISpM5ia23VArb6sujLDvUDjBPfuILyZenvNs r9p7ITcUCVh/xMLSl+5tkac3Erw9mkiqdmYajlfw8kkUU1Ju9l1EJstKENU6AOVhLxay 4evA== 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=Xdqgtfvzj0wFH+LQR4bCo7Wqao9ZJocu0ImQlJVorTA=; b=VxWG+BIcTT0xKRRcs5MMHc+CfuVhV4H/ahMlIKRYwX5ce2i1E/ZVmNB01AsOYoYvGs gTqsBAIg2NdLhpxBl42Zor+7Oea7KMxOYwCSCdFzKj/Egea1chqtAHWK+Pgf7nndYK9Y fIBseyWVsxQIFz0plLYm3qC7LhKM/1Iao6Ysu65C82dTWu99txuLmwC30CHS2nsbXMzj tc9RHJf9N7U4Mhr1UHxv2/A8xeEPzYogtKLCBM857m5MOoV2BO1DpxnmTfFzmjOmpQi3 TPOoY8l3KuYL7pv0+bLOcuS0DCokgNRoYCGo7G2DEdFQBu6630hea3aZrCO0U0rT0sTg /I/g== 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 Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qb10-20020a1709077e8a00b00947e2d50eb4si1367584ejc.68.2023.04.03.11.41.27; Mon, 03 Apr 2023 11:41:50 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233115AbjDCS2w (ORCPT <rfc822;zwp10758@gmail.com> + 99 others); Mon, 3 Apr 2023 14:28:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54284 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233101AbjDCS2j (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 3 Apr 2023 14:28:39 -0400 Received: from exchange.fintech.ru (e10edge.fintech.ru [195.54.195.159]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8EE64210D for <linux-kernel@vger.kernel.org>; Mon, 3 Apr 2023 11:28:36 -0700 (PDT) Received: from Ex16-01.fintech.ru (10.0.10.18) by exchange.fintech.ru (195.54.195.169) with Microsoft SMTP Server (TLS) id 14.3.498.0; Mon, 3 Apr 2023 21:28:28 +0300 Received: from localhost (10.0.253.157) by Ex16-01.fintech.ru (10.0.10.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Mon, 3 Apr 2023 21:28:28 +0300 From: Nikita Zhandarovich <n.zhandarovich@fintech.ru> To: Alex Deucher <alexander.deucher@amd.com> CC: Nikita Zhandarovich <n.zhandarovich@fintech.ru>, =?utf-8?q?Christian_K?= =?utf-8?q?=C3=B6nig?= <christian.koenig@amd.com>, "Pan, Xinhui" <Xinhui.Pan@amd.com>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, <amd-gfx@lists.freedesktop.org>, <dri-devel@lists.freedesktop.org>, <linux-kernel@vger.kernel.org>, <lvc-project@linuxtesting.org> Subject: [PATCH] radeon: avoid double free in ci_dpm_init() Date: Mon, 3 Apr 2023 11:28:08 -0700 Message-ID: <20230403182808.8699-1-n.zhandarovich@fintech.ru> 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.0.253.157] X-ClientProxiedBy: Ex16-02.fintech.ru (10.0.10.19) To Ex16-01.fintech.ru (10.0.10.18) X-Spam-Status: No, score=0.0 required=5.0 tests=SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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?1762181577015793743?= X-GMAIL-MSGID: =?utf-8?q?1762181577015793743?= |
Series |
radeon: avoid double free in ci_dpm_init()
|
|
Commit Message
Nikita Zhandarovich
April 3, 2023, 6:28 p.m. UTC
There are several calls to ci_dpm_fini() in ci_dpm_init() when there
occur errors in functions like r600_parse_extended_power_table().
This is harmful as it can lead to double free situations: for
instance, r600_parse_extended_power_table() will call for
r600_free_extended_power_table() as will ci_dpm_fini(), both
of which will try to free resources.
Other drivers do not call *_dpm_fini functions from their
respective *_dpm_init calls - neither should cpm_dpm_init().
Fix this by removing extra calls to ci_dpm_fini().
Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.
Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)")
Cc: stable@vger.kernel.org
Co-developed-by: Natalia Petrova <n.petrova@fintech.ru>
Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
---
drivers/gpu/drm/radeon/ci_dpm.c | 20 +++++---------------
1 file changed, 5 insertions(+), 15 deletions(-)
Comments
[Public] > -----Original Message----- > From: Nikita Zhandarovich <n.zhandarovich@fintech.ru> > Sent: Monday, April 3, 2023 2:28 PM > To: Deucher, Alexander <Alexander.Deucher@amd.com> > Cc: Nikita Zhandarovich <n.zhandarovich@fintech.ru>; Koenig, Christian > <Christian.Koenig@amd.com>; Pan, Xinhui <Xinhui.Pan@amd.com>; David > Airlie <airlied@gmail.com>; Daniel Vetter <daniel@ffwll.ch>; amd- > gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux- > kernel@vger.kernel.org; lvc-project@linuxtesting.org > Subject: [PATCH] radeon: avoid double free in ci_dpm_init() > > There are several calls to ci_dpm_fini() in ci_dpm_init() when there occur > errors in functions like r600_parse_extended_power_table(). > This is harmful as it can lead to double free situations: for instance, > r600_parse_extended_power_table() will call for > r600_free_extended_power_table() as will ci_dpm_fini(), both of which will > try to free resources. > Other drivers do not call *_dpm_fini functions from their respective > *_dpm_init calls - neither should cpm_dpm_init(). > > Fix this by removing extra calls to ci_dpm_fini(). You can't just drop the calls to fini(). You'll need to properly unwind to avoid leaking memory. Alex > > Found by Linux Verification Center (linuxtesting.org) with static analysis tool > SVACE. > > Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)") > Cc: stable@vger.kernel.org > Co-developed-by: Natalia Petrova <n.petrova@fintech.ru> > Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> > > --- > drivers/gpu/drm/radeon/ci_dpm.c | 20 +++++--------------- > 1 file changed, 5 insertions(+), 15 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/ci_dpm.c > b/drivers/gpu/drm/radeon/ci_dpm.c index 8ef25ab305ae..7b77d4c93f1d > 100644 > --- a/drivers/gpu/drm/radeon/ci_dpm.c > +++ b/drivers/gpu/drm/radeon/ci_dpm.c > @@ -5677,28 +5677,20 @@ int ci_dpm_init(struct radeon_device *rdev) > pi->pcie_lane_powersaving.min = 16; > > ret = ci_get_vbios_boot_values(rdev, &pi->vbios_boot_state); > - if (ret) { > - ci_dpm_fini(rdev); > + if (ret) > return ret; > - } > > ret = r600_get_platform_caps(rdev); > - if (ret) { > - ci_dpm_fini(rdev); > + if (ret) > return ret; > - } > > ret = r600_parse_extended_power_table(rdev); > - if (ret) { > - ci_dpm_fini(rdev); > + if (ret) > return ret; > - } > > ret = ci_parse_power_table(rdev); > - if (ret) { > - ci_dpm_fini(rdev); > + if (ret) > return ret; > - } > > pi->dll_default_on = false; > pi->sram_end = SMC_RAM_END; > @@ -5749,10 +5741,8 @@ int ci_dpm_init(struct radeon_device *rdev) > kcalloc(4, > sizeof(struct > radeon_clock_voltage_dependency_entry), > GFP_KERNEL); > - if (!rdev- > >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries) { > - ci_dpm_fini(rdev); > + if (!rdev- > >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries) > return -ENOMEM; > - } > rdev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.count = 4; > rdev- > >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].clk = 0; > rdev- > >pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].v = 0;
On 4/11/23 14:11, Deucher, Alexander wrote: > [Public] > >> -----Original Message----- >> From: Nikita Zhandarovich <n.zhandarovich@fintech.ru> >> Sent: Monday, April 3, 2023 2:28 PM >> To: Deucher, Alexander <Alexander.Deucher@amd.com> >> Cc: Nikita Zhandarovich <n.zhandarovich@fintech.ru>; Koenig, Christian >> <Christian.Koenig@amd.com>; Pan, Xinhui <Xinhui.Pan@amd.com>; David >> Airlie <airlied@gmail.com>; Daniel Vetter <daniel@ffwll.ch>; amd- >> gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux- >> kernel@vger.kernel.org; lvc-project@linuxtesting.org >> Subject: [PATCH] radeon: avoid double free in ci_dpm_init() >> >> There are several calls to ci_dpm_fini() in ci_dpm_init() when there occur >> errors in functions like r600_parse_extended_power_table(). >> This is harmful as it can lead to double free situations: for instance, >> r600_parse_extended_power_table() will call for >> r600_free_extended_power_table() as will ci_dpm_fini(), both of which will >> try to free resources. >> Other drivers do not call *_dpm_fini functions from their respective >> *_dpm_init calls - neither should cpm_dpm_init(). >> >> Fix this by removing extra calls to ci_dpm_fini(). > > You can't just drop the calls to fini(). You'll need to properly unwind to avoid leaking memory. > > Alex >>> >> Found by Linux Verification Center (linuxtesting.org) with static analysis tool >> SVACE. >> >> Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)") >> Cc: stable@vger.kernel.org >> Co-developed-by: Natalia Petrova <n.petrova@fintech.ru> >> Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> >> >> --- >> drivers/gpu/drm/radeon/ci_dpm.c | 20 +++++--------------- >> 1 file changed, 5 insertions(+), 15 deletions(-) >> >> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c >> b/drivers/gpu/drm/radeon/ci_dpm.c index 8ef25ab305ae..7b77d4c93f1d >> 100644 >> --- a/drivers/gpu/drm/radeon/ci_dpm.c >> +++ b/drivers/gpu/drm/radeon/ci_dpm.c >> @@ -5677,28 +5677,20 @@ int ci_dpm_init(struct radeon_device *rdev) >> pi->pcie_lane_powersaving.min = 16; >> >> ret = ci_get_vbios_boot_values(rdev, &pi->vbios_boot_state); >> - if (ret) { >> - ci_dpm_fini(rdev); >> + if (ret) >> return ret; >> - } >> >> ret = r600_get_platform_caps(rdev); >> - if (ret) { >> - ci_dpm_fini(rdev); >> + if (ret) >> return ret; >> - } >> >> ret = r600_parse_extended_power_table(rdev); >> - if (ret) { >> - ci_dpm_fini(rdev); >> + if (ret) >> return ret; >> - } >> >> ret = ci_parse_power_table(rdev); >> - if (ret) { >> - ci_dpm_fini(rdev); >> + if (ret) >> return ret; >> - } >> >> pi->dll_default_on = false; >> pi->sram_end = SMC_RAM_END; >> @@ -5749,10 +5741,8 @@ int ci_dpm_init(struct radeon_device *rdev) >> kcalloc(4, >> sizeof(struct >> radeon_clock_voltage_dependency_entry), >> GFP_KERNEL); >> - if (!rdev- >>> pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries) { >> - ci_dpm_fini(rdev); >> + if (!rdev- >>> pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries) >> return -ENOMEM; >> - } >> rdev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.count = 4; >> rdev- >>> pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].clk = 0; >> rdev- >>> pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].v = 0; I think you are correct when it comes to ensuring we deal with memory issues in ci_dpm_init(). However, I could use some direction on how to deal with the problem of freeing only previously allocated resources. For instance, once ci_parse_power_table() fails, it is not clear what we should and should not free. I wanna point out that in this case I would like to fix both double and uninitialized free issues as it can also lead to undefined behavior. Thanks for your patience, Nikita
On Wed, Apr 12, 2023 at 8:39 AM Nikita Zhandarovich <n.zhandarovich@fintech.ru> wrote: > > > > On 4/11/23 14:11, Deucher, Alexander wrote: > > [Public] > > > >> -----Original Message----- > >> From: Nikita Zhandarovich <n.zhandarovich@fintech.ru> > >> Sent: Monday, April 3, 2023 2:28 PM > >> To: Deucher, Alexander <Alexander.Deucher@amd.com> > >> Cc: Nikita Zhandarovich <n.zhandarovich@fintech.ru>; Koenig, Christian > >> <Christian.Koenig@amd.com>; Pan, Xinhui <Xinhui.Pan@amd.com>; David > >> Airlie <airlied@gmail.com>; Daniel Vetter <daniel@ffwll.ch>; amd- > >> gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux- > >> kernel@vger.kernel.org; lvc-project@linuxtesting.org > >> Subject: [PATCH] radeon: avoid double free in ci_dpm_init() > >> > >> There are several calls to ci_dpm_fini() in ci_dpm_init() when there occur > >> errors in functions like r600_parse_extended_power_table(). > >> This is harmful as it can lead to double free situations: for instance, > >> r600_parse_extended_power_table() will call for > >> r600_free_extended_power_table() as will ci_dpm_fini(), both of which will > >> try to free resources. > >> Other drivers do not call *_dpm_fini functions from their respective > >> *_dpm_init calls - neither should cpm_dpm_init(). > >> > >> Fix this by removing extra calls to ci_dpm_fini(). > > > > You can't just drop the calls to fini(). You'll need to properly unwind to avoid leaking memory. > > > > Alex > >>> > >> Found by Linux Verification Center (linuxtesting.org) with static analysis tool > >> SVACE. > >> > >> Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)") > >> Cc: stable@vger.kernel.org > >> Co-developed-by: Natalia Petrova <n.petrova@fintech.ru> > >> Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> > >> > >> --- > >> drivers/gpu/drm/radeon/ci_dpm.c | 20 +++++--------------- > >> 1 file changed, 5 insertions(+), 15 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/radeon/ci_dpm.c > >> b/drivers/gpu/drm/radeon/ci_dpm.c index 8ef25ab305ae..7b77d4c93f1d > >> 100644 > >> --- a/drivers/gpu/drm/radeon/ci_dpm.c > >> +++ b/drivers/gpu/drm/radeon/ci_dpm.c > >> @@ -5677,28 +5677,20 @@ int ci_dpm_init(struct radeon_device *rdev) > >> pi->pcie_lane_powersaving.min = 16; > >> > >> ret = ci_get_vbios_boot_values(rdev, &pi->vbios_boot_state); > >> - if (ret) { > >> - ci_dpm_fini(rdev); > >> + if (ret) > >> return ret; > >> - } > >> > >> ret = r600_get_platform_caps(rdev); > >> - if (ret) { > >> - ci_dpm_fini(rdev); > >> + if (ret) > >> return ret; > >> - } > >> > >> ret = r600_parse_extended_power_table(rdev); > >> - if (ret) { > >> - ci_dpm_fini(rdev); > >> + if (ret) > >> return ret; > >> - } > >> > >> ret = ci_parse_power_table(rdev); > >> - if (ret) { > >> - ci_dpm_fini(rdev); > >> + if (ret) > >> return ret; > >> - } > >> > >> pi->dll_default_on = false; > >> pi->sram_end = SMC_RAM_END; > >> @@ -5749,10 +5741,8 @@ int ci_dpm_init(struct radeon_device *rdev) > >> kcalloc(4, > >> sizeof(struct > >> radeon_clock_voltage_dependency_entry), > >> GFP_KERNEL); > >> - if (!rdev- > >>> pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries) { > >> - ci_dpm_fini(rdev); > >> + if (!rdev- > >>> pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries) > >> return -ENOMEM; > >> - } > >> rdev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.count = 4; > >> rdev- > >>> pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].clk = 0; > >> rdev- > >>> pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].v = 0; > > > I think you are correct when it comes to ensuring we deal with memory > issues in ci_dpm_init(). > > However, I could use some direction on how to deal with the problem of > freeing only previously allocated resources. For instance, once > ci_parse_power_table() fails, it is not clear what we should and should > not free. You'll want to free any memory allocated in ci_dpm_init(). Any of the functions called from that function should clean themselves up if they allocate any memory, but if not, they should be fixed. Alex > > I wanna point out that in this case I would like to fix both double and > uninitialized free issues as it can also lead to undefined behavior. > > Thanks for your patience, > Nikita
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c index 8ef25ab305ae..7b77d4c93f1d 100644 --- a/drivers/gpu/drm/radeon/ci_dpm.c +++ b/drivers/gpu/drm/radeon/ci_dpm.c @@ -5677,28 +5677,20 @@ int ci_dpm_init(struct radeon_device *rdev) pi->pcie_lane_powersaving.min = 16; ret = ci_get_vbios_boot_values(rdev, &pi->vbios_boot_state); - if (ret) { - ci_dpm_fini(rdev); + if (ret) return ret; - } ret = r600_get_platform_caps(rdev); - if (ret) { - ci_dpm_fini(rdev); + if (ret) return ret; - } ret = r600_parse_extended_power_table(rdev); - if (ret) { - ci_dpm_fini(rdev); + if (ret) return ret; - } ret = ci_parse_power_table(rdev); - if (ret) { - ci_dpm_fini(rdev); + if (ret) return ret; - } pi->dll_default_on = false; pi->sram_end = SMC_RAM_END; @@ -5749,10 +5741,8 @@ int ci_dpm_init(struct radeon_device *rdev) kcalloc(4, sizeof(struct radeon_clock_voltage_dependency_entry), GFP_KERNEL); - if (!rdev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries) { - ci_dpm_fini(rdev); + if (!rdev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries) return -ENOMEM; - } rdev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.count = 4; rdev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].clk = 0; rdev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries[0].v = 0;