Double free vulnerability in do_rename_gpt_parts
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.
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
+ Some contributors of this file
On Fri, Jan 17, 2020 at 1:03 PM Jordy jordy@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
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 jordy@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...
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!
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 jordy@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...
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
Hey Tom,
The patch looks good to me, I do agree with simon that you'd have to initialize the pointers to 0, because uninitialized pointers could contain garbage, unless it's a global variable (those are automagically initialized to 0).
Btw I really appreciate the fast and friendly responses, I've seen that different at other software packages thumbs-up for that!
Best Regards,
Jordy
On January 17, 2020 11:31 AM Tom Rini trini@konsulko.com wrote:
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 jordy@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...
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!
-- Tom
participants (3)
-
Jordy -
Simon Goldschmidt -
Tom Rini