lkml.org 
[lkml]   [2022]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [Linaro-mm-sig] [PATCH next] dma-buf/sync-file: do not allow zero size allocations
From
Hi Christian,

On 3/30/22 10:09, Christian König wrote:
> That problem is already fixed with patch 21d139d73f77 dma-buf/sync-file:
> fix logic error in new fence merge code.
>
> Am 30.03.22 um 00:14 schrieb Pavel Skripkin:
>> syzbot reported GPF in dma_fence_array_first(), which is caused by
>> dereferencing ZERO_PTR in dma-buf internals.
>>
>> ZERO_PTR was generated in sync_file_merge(). This functuion tries to
>> reduce allocation size, but does not check if it reducing to 0.
>
> This is actually perfectly ok. The code above should have prevented the
> size to become 0.
>
> Regards,
> Christian.
>

Thanks for your reply! I see that 21d139d73f77 fixes GPF in
dma_fence_array_first(), but what about this part:

>>
>> - if (num_fences > INT_MAX)
>> + if (num_fences > INT_MAX || !num_fences)
>> goto err_free_sync_file;
>>
>> fences = kcalloc(num_fences, sizeof(*fences), GFP_KERNEL);
>> @@ -264,7 +264,7 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a,
>> if (index == 0)

If num_fences is equal to zero then fences dereference will cause an
oops. Or this one is also fixed in your tree?


Thanks!




With regards,
Pavel Skripkin

\
 
 \ /
  Last update: 2022-03-30 20:30    [W:0.180 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site