[FFmpeg-devel] [PATCH 3/3] avcodec/huffyuvdec: Check input buffer size
michael at niedermayer.cc
Thu Feb 1 03:36:16 EET 2018
On Wed, Jan 31, 2018 at 07:56:06PM +0100, Paul B Mahol wrote:
> On 1/31/18, Michael Niedermayer <michael at 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 <michael at 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
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: not available
More information about the ffmpeg-devel