linux-kernel - Re: [Linaro-mm-sig] [PATCH next] dma-buf/sync-file: do not allow zero size allocations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 30 Mar 2022 21:24:48 +0300
From:   Pavel Skripkin <paskripkin@...il.com>
To:     Christian König <ckoenig.leichtzumerken@...il.com>,
        sumit.semwal@...aro.org, gustavo@...ovan.org,
        christian.koenig@....com, daniel.vetter@...ll.ch
Cc:     linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linaro-mm-sig@...ts.linaro.org, linux-kernel@...r.kernel.org,
        syzbot+5c943fe38e86d615cac2@...kaller.appspotmail.com
Subject: Re: [Linaro-mm-sig] [PATCH next] dma-buf/sync-file: do not allow zero
 size allocations

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