Philippe Mathieu-Daudé <phi...@redhat.com> writes:
> On 4/9/19 7:40 PM, Markus Armbruster wrote:
>> If the value of get_image_size() exceeds INT_MAX / 2 - 10000, the
>> computation of @dt_size overflows to a negative number, which then
>> gets converted to a very large size_t for g_malloc0() and
>> load_image_size(). In the (fortunately improbable) case g_malloc0()
>> succeeds and load_image_size() survives, we'd assign the negative
>> number to *sizep. What that would do to the callers I can't say, but
>> it's unlikely to be good.
>>
>> Fix by rejecting images whose size would overflow.
>>
>> Signed-off-by: Markus Armbruster <arm...@redhat.com>
>> ---
>> device_tree.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/device_tree.c b/device_tree.c
>> index 296278e12a..f8b46b3c73 100644
>> --- a/device_tree.c
>> +++ b/device_tree.c
>> @@ -84,6 +84,10 @@ void *load_device_tree(const char *filename_path, int
>> *sizep)
>> filename_path);
>> goto fail;
>> }
>> + if (dt_size > INT_MAX / 2 - 10000) {
>
> We should avoid magic number duplication.
> That said, this patch looks safe.
>
> Reviewed-by: Philippe Mathieu-Daudé <phi...@redhat.com>
Thanks!
> BTW how did you figure that out?
Downstream handling of upstream commit da885fe1ee8 led me to the
function. I spotted dt_size = get_image_size(filename_path).
Experience has taught me to check the left hand side's type. Bad. Then
I saw how dt_size gets increased. Worse.
>> + error_report("Device tree file '%s' is too large", filename_path);
>> + goto fail;
>> + }
>>
>> /* Expand to 2x size to give enough room for manipulation. */
>> dt_size += 10000;
>>
