Messages in this thread | | | Date | Thu, 31 Mar 2022 08:23:32 +0200 | Subject | Re: [Linaro-mm-sig] [PATCH next] dma-buf/sync-file: do not allow zero size allocations | From | Christian König <> |
| |
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
| |