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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel