[FFmpeg-devel] [PATCH 3/3] avcodec/huffyuvdec: Check input buffer size

[Michael Niedermayer]

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
            conveniently.
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...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180201/2665b398/attachment.sig>