From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Goldschmidt Date: Fri, 17 Jan 2020 17:42:16 +0100 Subject: Double free vulnerability in do_rename_gpt_parts In-Reply-To: <20200117163149.GV8732@bill-the-cat> References: <1646688175.190878.1579262589951@privateemail.com> <20200117163149.GV8732@bill-the-cat> Message-ID: <94cf8c43-260f-7d65-7def-a195c35ef967@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Am 17.01.2020 um 17:31 schrieb Tom Rini: > On Fri, Jan 17, 2020 at 04:29:52PM +0100, Simon Goldschmidt wrote: >> + 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... > > So, Coverity later did complain about that change (but not immediately, > funny enough). I posted http://patchwork.ozlabs.org/patch/1192036/ and > was hoping for a review on it as it's complex enough I'd like to avoid > adding a 3rd round of issues there. Thanks! > Ah, yes. I've just responded there. Regards, Simon