lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5d5b0b94-4dd4-2a95-a777-521b65f6f053@fintech.ru>
Date:   Wed, 12 Apr 2023 05:39:04 -0700
From:   Nikita Zhandarovich <n.zhandarovich@...tech.ru>
To:     "Deucher, Alexander" <Alexander.Deucher@....com>
CC:     "Koenig, Christian" <Christian.Koenig@....com>,
        "Pan, Xinhui" <Xinhui.Pan@....com>,
        David Airlie <airlied@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        "amd-gfx@...ts.freedesktop.org" <amd-gfx@...ts.freedesktop.org>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "lvc-project@...uxtesting.org" <lvc-project@...uxtesting.org>
Subject: Re: [PATCH] radeon: avoid double free in ci_dpm_init()



On 4/11/23 14:11, Deucher, Alexander wrote:
> [Public]
> 
>> -----Original Message-----
>> From: Nikita Zhandarovich <n.zhandarovich@...tech.ru>
>> Sent: Monday, April 3, 2023 2:28 PM
>> To: Deucher, Alexander <Alexander.Deucher@....com>
>> Cc: Nikita Zhandarovich <n.zhandarovich@...tech.ru>; Koenig, Christian
>> <Christian.Koenig@....com>; Pan, Xinhui <Xinhui.Pan@....com>; David
>> Airlie <airlied@...il.com>; Daniel Vetter <daniel@...ll.ch>; amd-
>> gfx@...ts.freedesktop.org; dri-devel@...ts.freedesktop.org; linux-
>> kernel@...r.kernel.org; lvc-project@...uxtesting.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@...r.kernel.org
>> Co-developed-by: Natalia Petrova <n.petrova@...tech.ru>
>> Signed-off-by: Nikita Zhandarovich <n.zhandarovich@...tech.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ