| Message ID | 20190815214915.909-1-michael@niedermayer.cc |
|---|---|
| State | New |
| Headers | show |
NAK On Thu, Aug 15, 2019 at 11:51 PM Michael Niedermayer <michael@niedermayer.cc> wrote: > Fixes: overflow in aspect ratio calculation > 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 > <https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by>: > Michael Niedermayer <michael@niedermayer.cc> > --- > libavcodec/vc1dec.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c > index 9519864c55..2636ea701f 100644 > --- a/libavcodec/vc1dec.c > +++ b/libavcodec/vc1dec.c > @@ -426,6 +426,11 @@ static av_cold int vc1_decode_init(AVCodecContext > *avctx) > GetBitContext gb; > int ret; > > + if (avctx->width > 1 << 14 || avctx->height > 1 << 14) { > + avpriv_request_sample(avctx, "Huge resolution"); > + return AVERROR_PATCHWELCOME; > + } > + > /* save the container output size for WMImage */ > v->output_width = avctx->width; > v->output_height = avctx->height; > -- > 2.22.1 > > _______________________________________________ > 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".
You need to explain why. A "NAK" is not enough. 16k pixels x 16k is a large size already for vc1. On Sun, Aug 18, 2019, at 12:45, Paul B Mahol wrote: > NAK > > On Thu, Aug 15, 2019 at 11:51 PM Michael Niedermayer <michael@niedermayer.cc> > wrote: > > > Fixes: overflow in aspect ratio calculation > > 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 > > <https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by>: > > Michael Niedermayer <michael@niedermayer.cc> > > --- > > libavcodec/vc1dec.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c > > index 9519864c55..2636ea701f 100644 > > --- a/libavcodec/vc1dec.c > > +++ b/libavcodec/vc1dec.c > > @@ -426,6 +426,11 @@ static av_cold int vc1_decode_init(AVCodecContext > > *avctx) > > GetBitContext gb; > > int ret; > > > > + if (avctx->width > 1 << 14 || avctx->height > 1 << 14) { > > + avpriv_request_sample(avctx, "Huge resolution"); > > + return AVERROR_PATCHWELCOME; > > + } > > + > > /* save the container output size for WMImage */ > > v->output_width = avctx->width; > > v->output_height = avctx->height; > > -- > > 2.22.1 > > > > _______________________________________________ > > 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". > _______________________________________________ > 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".
On Mon, Aug 19, 2019 at 8:17 AM Jean-Baptiste Kempf <jb@videolan.org> wrote: > You need to explain why. A "NAK" is not enough. > > 16k pixels x 16k is a large size already for vc1. > And for any other codecs.... > > On Sun, Aug 18, 2019, at 12:45, Paul B Mahol wrote: > > NAK > > > > On Thu, Aug 15, 2019 at 11:51 PM Michael Niedermayer > <michael@niedermayer.cc> > > wrote: > > > > > Fixes: overflow in aspect ratio calculation > > > 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 > > > < > https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by > >: > > > Michael Niedermayer <michael@niedermayer.cc> > > > --- > > > libavcodec/vc1dec.c | 5 +++++ > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c > > > index 9519864c55..2636ea701f 100644 > > > --- a/libavcodec/vc1dec.c > > > +++ b/libavcodec/vc1dec.c > > > @@ -426,6 +426,11 @@ static av_cold int vc1_decode_init(AVCodecContext > > > *avctx) > > > GetBitContext gb; > > > int ret; > > > > > > + if (avctx->width > 1 << 14 || avctx->height > 1 << 14) { > > > + avpriv_request_sample(avctx, "Huge resolution"); > > > + return AVERROR_PATCHWELCOME; > > > + } > > > + > > > /* save the container output size for WMImage */ > > > v->output_width = avctx->width; > > > v->output_height = avctx->height; > > > -- > > > 2.22.1 > > > > > > _______________________________________________ > > > 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". > > _______________________________________________ > > 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". > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > _______________________________________________ > 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".
On Mon, Aug 19, 2019, at 09:45, Paul B Mahol wrote: > On Mon, Aug 19, 2019 at 8:17 AM Jean-Baptiste Kempf <jb@videolan.org> wrote: > > > You need to explain why. A "NAK" is not enough. > > > > 16k pixels x 16k is a large size already for vc1. > > > > And for any other codecs.... Sure. In VLC we limit to 8k x 8k for all codecs. But what is your counter-proposal?
On Mon, Aug 19, 2019 at 9:46 AM Jean-Baptiste Kempf <jb@videolan.org> wrote: > > > On Mon, Aug 19, 2019, at 09:45, Paul B Mahol wrote: > > On Mon, Aug 19, 2019 at 8:17 AM Jean-Baptiste Kempf <jb@videolan.org> > wrote: > > > > > You need to explain why. A "NAK" is not enough. > > > > > > 16k pixels x 16k is a large size already for vc1. > > > > > > > And for any other codecs.... > > Sure. > In VLC we limit to 8k x 8k for all codecs. > > But what is your counter-proposal? > > To leave this code as is. > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > _______________________________________________ > 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".
mån 2019-08-19 klockan 08:17 +0200 skrev Jean-Baptiste Kempf: > You need to explain why. A "NAK" is not enough. > > 16k pixels x 16k is a large size already for vc1. Why not fix the calculation? 16K is a thing, and larger resolutions are inevitable.. /Tomas
On Mon, Aug 19, 2019, at 11:02, Tomas Härdin wrote: > mån 2019-08-19 klockan 08:17 +0200 skrev Jean-Baptiste Kempf: > > You need to explain why. A "NAK" is not enough. > > > > 16k pixels x 16k is a large size already for vc1. > > Why not fix the calculation? 16K is a thing, and larger resolutions are > inevitable.. 16K is not 16K * 16K. Also, VC1 does not support those resolution.
mån 2019-08-19 klockan 11:19 +0200 skrev Jean-Baptiste Kempf: > > On Mon, Aug 19, 2019, at 11:02, Tomas Härdin wrote: > > mån 2019-08-19 klockan 08:17 +0200 skrev Jean-Baptiste Kempf: > > > You need to explain why. A "NAK" is not enough. > > > > > > 16k pixels x 16k is a large size already for vc1. > > > > Why not fix the calculation? 16K is a thing, and larger resolutions > > are > > inevitable.. > > 16K is not 16K * 16K. Also, VC1 does not support those resolution. Why not use max_coded_width/height then? Seems vc1.c limits both to [2,8192] /Tomas
diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c index 9519864c55..2636ea701f 100644 --- a/libavcodec/vc1dec.c +++ b/libavcodec/vc1dec.c @@ -426,6 +426,11 @@ static av_cold int vc1_decode_init(AVCodecContext *avctx) GetBitContext gb; int ret; + if (avctx->width > 1 << 14 || avctx->height > 1 << 14) { + avpriv_request_sample(avctx, "Huge resolution"); + return AVERROR_PATCHWELCOME; + } + /* save the container output size for WMImage */ v->output_width = avctx->width; v->output_height = avctx->height;
Fixes: overflow in aspect ratio calculation 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/vc1dec.c | 5 +++++ 1 file changed, 5 insertions(+)