From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Fri, 17 Jan 2020 16:29:52 +0100 Subject: Double free vulnerability in do_rename_gpt_parts In-Reply-To: <1646688175.190878.1579262589951@privateemail.com> References: <1646688175.190878.1579262589951@privateemail.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de + Some contributors of this file On Fri, Jan 17, 2020 at 1:03 PM Jordy wrote: > > Hello U-Boot lists! > > I think I found a double free bug in U-Boot, in /cmp/gpt.c in the function do_rename_gpt_parts(). > > On line 702 the partition_list is being free'd if ret is smaller than 0. > If the return value is not -ENOMEM it will go to the out: label and free the partition_list again. Reading the code, I can confirm that. Funny enough, the code in question was introduced by commit 18030d04 ("GPT: fix memory leaks identified by Coverity"). Although I think Coverity should have detected the resulting double-free... However, I'm not sure of the fix: the code just continues for -ENOMEM and then goes on using partitions_list at line 757... Regards, Simon > > Double freeing may result in a write-what-where condition, allowing an attacker to execute arbitrary code. > > My advice would be to not free the parition_list on line 702 as nothing is being done with it there afterwards anyway and leave your clean_up in the out: label :) > > Kind Regards, > > Jordy Zomer