| Message ID | 20180131182010.8745-3-michael@niedermayer.cc |
|---|---|
| State | Accepted |
| Commit | 08c220d26cff51ca2f6896b65aebfa3accc67290 |
| Headers | show |
On 1/31/18, Michael Niedermayer <michael@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@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? Something similar you had already posted long ago.
On Wed, Jan 31, 2018 at 07:56:06PM +0100, Paul B Mahol wrote: > On 1/31/18, Michael Niedermayer <michael@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@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 ? [...]
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 <michael@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@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 [...]
On 2/5/18, Michael Niedermayer <michael@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 <michael@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@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?
On Mon, Feb 05, 2018 at 10:04:47AM +0100, Paul B Mahol wrote: > On 2/5/18, Michael Niedermayer <michael@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 <michael@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@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? huffyuv encodes samples using huffman codes, the smallest is 1 bit so w*h bits should be the minimum Am i missing something ? [...]
On 2/5/18, Michael Niedermayer <michael@niedermayer.cc> wrote: > On Mon, Feb 05, 2018 at 10:04:47AM +0100, Paul B Mahol wrote: >> On 2/5/18, Michael Niedermayer <michael@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 <michael@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@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? > > huffyuv encodes samples using huffman codes, the smallest is 1 bit so > w*h bits should be the minimum > > ok
On Thu, Feb 08, 2018 at 06:09:46PM +0100, Paul B Mahol wrote: > On 2/5/18, Michael Niedermayer <michael@niedermayer.cc> wrote: > > On Mon, Feb 05, 2018 at 10:04:47AM +0100, Paul B Mahol wrote: > >> On 2/5/18, Michael Niedermayer <michael@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 <michael@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@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? > > > > huffyuv encodes samples using huffman codes, the smallest is 1 bit so > > w*h bits should be the minimum > > > > > > ok will apply thx [...]
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; + av_fast_padded_malloc(&s->bitstream_buffer, &s->bitstream_buffer_size, buf_size);
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@niedermayer.cc> --- libavcodec/huffyuvdec.c | 3 +++ 1 file changed, 3 insertions(+)