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 ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel