linux-kernel - Re: [PATCH] platform/x86: alienware-wmi: fix kfree on potentially uninitialized pointer

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]

Date:   Wed, 3 Apr 2019 23:27:52 +0100
From:   Colin Ian King <colin.king@...onical.com>
To:     Darren Hart <dvhart@...radead.org>
Cc:     Andy Shevchenko <andy@...radead.org>,
        platform-driver-x86@...r.kernel.org,
        kernel-janitors@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] platform/x86: alienware-wmi: fix kfree on potentially
 uninitialized pointer

On 03/04/2019 23:26, Darren Hart wrote:
> On Wed, Apr 03, 2019 at 11:05:12PM +0100, Colin Ian King wrote:
>> On 03/04/2019 23:02, Darren Hart wrote:
>>> On Sat, Mar 30, 2019 at 12:17:12AM +0000, Colin King wrote:
>>>> From: Colin Ian King <colin.king@...onical.com>
>>>>
>>>> Currently the kfree of output.pointer can be potentially freeing
>>>> an uninitalized pointer in the case where out_data is NULL. Fix this
>>>> by reworking the case where out_data is not-null to perform the
>>>> ACPI status check and also the kfree of outpoint.pointer in one block
>>>> and hence ensuring the pointer is only freed when it has been used.
>>>>
>>>> Also replace the if (ptr != NULL) idiom with just if (ptr).
>>>>
>>>> Fixes: ff0e9f26288d ("platform/x86: alienware-wmi: Correct a memory leak")
>>>> Signed-off-by: Colin Ian King <colin.king@...onical.com>
>>>
>>> Thanks for the catch Colin, queued for testing.
>>>
>>> Did you trigger this error or detect it via review or static analysis?
>>>
>> Static analysis, I'm now running a licensed version of Coverity on one
>> of our servers.
> 
> We typically include the tool used to identify such bugs, and I see several such
> tags for Coverity in the logs. Was there a reason not to include that tag? If
> just an oversight, can you provide that tag and I'll amend the commit.
> 
I didn't have an external coverity CID# number so I omitted it this time.