[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