Double free vulnerability in do_rename_gpt_parts
Simon Goldschmidt
simon.k.r.goldschmidt at gmail.com
Fri Jan 17 16:29:52 CET 2020
+ Some contributors of this file
On Fri, Jan 17, 2020 at 1:03 PM Jordy <jordy at simplyhacker.com> 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
More information about the U-Boot
mailing list