linux-kernel - Re: [PATCH] drm/amdgpu: fix memory leak

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] [day] [month] [year] [list]

Message-ID: <d5dc0a2d-4950-d85a-a45b-5e8e0eda6447@amd.com>
Date:   Fri, 4 Oct 2019 11:36:09 +0000
From:   Nirmoy <nirmodas@....com>
To:     "Koenig, Christian" <Christian.Koenig@....com>,
        "Das, Nirmoy" <Nirmoy.Das@....com>,
        Nirmoy Das <nirmoy.aiemd@...il.com>,
        "Deucher, Alexander" <Alexander.Deucher@....com>
CC:     "airlied@...ux.ie" <airlied@...ux.ie>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/amdgpu: fix memory leak


On 10/4/19 1:30 PM, Koenig, Christian wrote:
> Am 04.10.19 um 13:26 schrieb Das, Nirmoy:
>> On 10/4/19 1:13 PM, Koenig, Christian wrote:
>>>>> NAK, that is a double free. The bo list entries are freed by
>>>>> amdgpu_bo_list_put().
>>>> Thanks, didn't realize that.
>>> Wait a second, what entries are you talking about?
>>>
>>> The entries in the list object are freed when amdgpu_bo_list_put() is
>>> called, but the temporary info array with the handles needs to be freed
>>> as well.
>>>
>>> And it looks like that is indeed leaked here.
>> I am talking about the `info` array created by
>> amdgpu_bo_create_list_entry_array().
> Yeah, that are the handles and not the entries. Sorry that I was
> confused about that.
>
> Your patch is correct, you should just update the commit message a bit.
>
> BTW: Could you cleanup error handling here a bit more?
>
> E.g. add an error_put_list handle and drop the "if (info)" and instead
> return directly if we fail to allocate info.
Okay I will do that in v2 of this patch.
> Thanks,
> Christian.


Regards,

Nirmoy