[FFmpeg-devel] [PATCH] avcodec/h264_parse: Use 64bit for expectedpoc

[James Almer]

On 5/23/2019 8:25 PM, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -2142516591 + -267814575 cannot be represented in type 'int'
> Fixes: 14450/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5716105319940096
> 
> Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael at niedermayer.cc>
> ---
>  libavcodec/h264_parse.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
> index a075443d17..cc72a1b263 100644
> --- a/libavcodec/h264_parse.c
> +++ b/libavcodec/h264_parse.c
> @@ -301,7 +301,8 @@ int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,
>          if (picture_structure == PICT_FRAME)
>              field_poc[1] += pc->delta_poc_bottom;
>      } else if (sps->poc_type == 1) {
> -        int abs_frame_num, expected_delta_per_poc_cycle, expectedpoc;
> +        int abs_frame_num, expected_delta_per_poc_cycle;

expected_delta_per_poc_cycle should also be int64_t. If you look at the
code below this chunk, it's set with the sum of all
sps->offset_for_ref_frame[] values (up to 255 of them), each of which
can be as high as INT32_MAX, so might as well change it now instead of
waiting for the fuzzer to trip on it.

> +        int64_t expectedpoc;
>          int i;
>  
>          if (sps->poc_cycle_length != 0)
>