[Linaro-mm-sig] [PATCH next] dma-buf/sync-file: do not allow zero size allocations
Christian König
ckoenig.leichtzumerken at gmail.com
Thu Mar 31 06:23:32 UTC 2022
Am 30.03.22 um 20:24 schrieb Pavel Skripkin:
> 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?
Well it is illegal for sync_file->fence to be NULL or we would run into
NULL pointer dereference much more often, so num_fences can't be zero
here either.
Regards,
Christian.
>
>
> Thanks!
>
>
>
>
> With regards,
> Pavel Skripkin
More information about the dri-devel
mailing list