diff mbox

[FFmpeg-devel,2/5] avcodec/vc1: Fix overflow in aspect ratio calculation

Message ID 20190808232350.16076-2-michael@niedermayer.cc
State New
Headers show

Commit Message

Michael Niedermayer Aug. 8, 2019, 11:23 p.m. UTC
Fixes: signed integer overflow: 393215 * 14594 cannot be represented in type 'int'
Fixes: 15728/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV3IMAGE_fuzzer-5661588893204480

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavcodec/vc1.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Jean-Baptiste Kempf Aug. 13, 2019, 8:56 a.m. UTC | #1
Are those values even acceptable according to spec?
Shouldn't 16k*16K be the maximum allowed?

On Fri, Aug 9, 2019, at 01:26, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 393215 * 14594 cannot be represented in 
> type 'int'
> Fixes: 
> 15728/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV3IMAGE_fuzzer-5661588893204480
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
> ---
>  libavcodec/vc1.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vc1.c b/libavcodec/vc1.c
> index e102b931d8..0790eb160e 100644
> --- a/libavcodec/vc1.c
> +++ b/libavcodec/vc1.c
> @@ -453,8 +453,8 @@ static int decode_sequence_header_adv(VC1Context 
> *v, GetBitContext *gb)
>          } else {
>              av_reduce(&v->s.avctx->sample_aspect_ratio.num,
>                        &v->s.avctx->sample_aspect_ratio.den,
> -                      v->s.avctx->height * w,
> -                      v->s.avctx->width * h,
> +                      v->s.avctx->height * (int64_t)w,
> +                      v->s.avctx->width * (int64_t)h,
>                        1 << 30);
>          }
>          ff_set_sar(v->s.avctx, v->s.avctx->sample_aspect_ratio);
> -- 
> 2.22.0
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Michael Niedermayer Aug. 15, 2019, 7:54 a.m. UTC | #2
On Tue, Aug 13, 2019 at 10:56:03AM +0200, Jean-Baptiste Kempf wrote:
> Are those values even acceptable according to spec?

Which spec ?
SMPTE 421M ?
no, i think not

wmv3image (which is what the fuzzer tested)
iam not sure if we have a spec about it.


> Shouldn't 16k*16K be the maximum allowed?

I can add a test, ask for a sample and fail instead.
I guess being more restrictive on this here is a good thing
so ill post a new patch with that

Thanks

[...]
diff mbox

Patch

diff --git a/libavcodec/vc1.c b/libavcodec/vc1.c
index e102b931d8..0790eb160e 100644
--- a/libavcodec/vc1.c
+++ b/libavcodec/vc1.c
@@ -453,8 +453,8 @@  static int decode_sequence_header_adv(VC1Context *v, GetBitContext *gb)
         } else {
             av_reduce(&v->s.avctx->sample_aspect_ratio.num,
                       &v->s.avctx->sample_aspect_ratio.den,
-                      v->s.avctx->height * w,
-                      v->s.avctx->width * h,
+                      v->s.avctx->height * (int64_t)w,
+                      v->s.avctx->width * (int64_t)h,
                       1 << 30);
         }
         ff_set_sar(v->s.avctx, v->s.avctx->sample_aspect_ratio);