On 2/5/18, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Thu, Feb 01, 2018 at 02:36:16AM +0100, Michael Niedermayer wrote: >> On Wed, Jan 31, 2018 at 07:56:06PM +0100, Paul B Mahol wrote: >> > On 1/31/18, Michael Niedermayer <mich...@niedermayer.cc> wrote: >> > > Fixes: Timeout >> > > Fixes: 5487/clusterfuzz-testcase-4696837035393024 >> > > >> > > Found-by: continuous fuzzing process >> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> > > Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc> >> > > --- >> > > libavcodec/huffyuvdec.c | 3 +++ >> > > 1 file changed, 3 insertions(+) >> > > >> > > diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c >> > > index 979c4b9d5c..66357bfb40 100644 >> > > --- a/libavcodec/huffyuvdec.c >> > > +++ b/libavcodec/huffyuvdec.c >> > > @@ -919,6 +919,9 @@ static int decode_frame(AVCodecContext *avctx, >> > > void >> > > *data, int *got_frame, >> > > AVFrame *const p = data; >> > > int table_size = 0, ret; >> > > >> > > + if (buf_size < (width * height + 7)/8) >> > > + return AVERROR_INVALIDDATA; >> > > + >> > >> > Are you sure this is enough? >> >> I dont know if thats the only way the decoder can be made to waste >> large amounts of CPU with little input data >> >> I do belive it stops this specific class of issues though >> >> >> > >> > Something similar you had already posted long ago. >> >> for other decoders, yes. Did i forget a patch for huffyuv ? > > i will apply this in a few days unless someone has objections or > sees some possible imrpovment
Are you sure this does not break decoding of valid files? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
