[FFmpeg-devel] [PATCH v1] avutil/frame: Use av_realloc_array()

James Almer jamrial at gmail.com
Tue Dec 24 03:20:37 EET 2019


On 12/23/2019 8:32 PM, Michael Niedermayer wrote:
> On Mon, Dec 23, 2019 at 10:48:13PM +0800, lance.lmwang at gmail.com wrote:
>> From: Limin Wang <lance.lmwang at gmail.com>
>>
>> Signed-off-by: Limin Wang <lance.lmwang at gmail.com>
>> ---
>>  libavutil/frame.c | 7 ++-----
>>  1 file changed, 2 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavutil/frame.c b/libavutil/frame.c
>> index 1d0faec687..0a1ba877cc 100644
>> --- a/libavutil/frame.c
>> +++ b/libavutil/frame.c
>> @@ -696,11 +696,8 @@ AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
>>      if (!buf)
>>          return NULL;
>>  
>> -    if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
>> -        return NULL;
>> -
>> -    tmp = av_realloc(frame->side_data,
>> -                     (frame->nb_side_data + 1) * sizeof(*frame->side_data));
>> +    tmp = av_realloc_array(frame->side_data,
>> +                     (frame->nb_side_data + 1), sizeof(*frame->side_data));
> 
> does something prevent "frame->nb_side_data + 1" from overflowing ?

av_realloc_array() is called with x + 1 as nmemb argument in several
places. It checks for "nmemb >= INT_MAX / size", so it will never
overflow with a buffer that increases by one element at a time (It would
if the check was > alone).

The version 2 of this patch is pointless since it adds an extra check to
the process, so if this one isn't applied then IMO none should.

> 
> thx
> 
> [...]
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> 



More information about the ffmpeg-devel mailing list